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This application claims the benefit of priority under 35 U.S.C. §1 19(e) to United 
States provisional patent application no. 60/458,829, filed March 26, 2003. 

FIELD OF THE INVENTION 
The present invention relates generally to automating tasks on the World Wide 
15 Web (the "Web") and more particularly to automating tasks for an online buyer or user 
, such as comparison shopping or interacting with the multilingual vendors on the World 
, Wide Web through a single interface to increase communication efficiencies and to 
provide a personalized buying experience in particular through a mobile implementation. 

DESCRIPTION OF THE BACKGROUND 
20 Since the creation of the World Wide Web in the mid 1 990's, the size of the 

Internet has exploded a thousand-fold. People are now inter-connected, not by means 
of direct face-to-face interaction, but through virtual communication channels. This new 
revolution of technology has fundamentally changed the way people live. 

A parallel development with the World Wide Web is the "Information Technology 
25 Age" that presents a stunning variety of online information resources ranging from 

product information to academic papers. These elements have enabled the exponential 
growth of Electronic Commerce that capitalizes on the convenience and low cost which 
the Internet delivers. 

There are several million or more online vendors on the World Wide Web. 
30 Although current comparison shopping or price comparison search engines can retrieve 
from different online competitors, according to aaonline buyer's or user's query, 
somewhat relevant search results pertinent to any desired products requested and their 
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desired prices, the buyer or user can be confronted with an endless sea of information. 
Sometimes, the buyer or user receives a "failure page" of search results because the 
search engines have missed other Websites of online multilingual vendors existing in 
the rest of the Internet-connected countries (currently numbering 245) selling exactly 
5 what was requested. Furthermore, although information about products and vendors is 
easily accessible on the Web, buyers or users are still in the loop in all stages of the 
buying process. 

The potential of the Internet for transforming the present mode of e-commerce 
into a truly global ensemble marketplace is largely unrealized today, and electronic 

10 purchases are still non-automated. Buying on the Internet is far from being simple, 
efficient, or enjoyable. Search engines and centralized directory services are 
insufficient for locating products the online buyer wants and the merchants willing to sell 
such products or services. Furthermore, the typical online purchase procedure is 
mostly manually driven and requires the buyer to enter all terms and keywords for which 

15 he or she wants to search. Therefore, a prospective buyer is faced with a daunting 
task, with responsibility for collecting and interpreting information about merchants and 
products, making decisions about them, and ultimately entering purchase and payment 
information. The scenario is that the user or buyer is easily overloaded with information 
without sufficient time and expertise. 

20 In order of complexity, there are two imperfect strategies presently adopted and 

implemented to partially automate an online catalog price comparison process as 
follows: 

(1) Non real-time approach 

(2) Real-time hard-coded wrappers approach 

25 The non real-time approach is the simplest way to implement a price comparison 

agent. Its implementation involves manually collecting all necessary information from 
the Web, and then writing a separate HTML file for each item of the search results in 
order to visually display the search results. 

The benefits of the above are obvious — easy implementation and short searching 

30 time. Notwithstanding those benefits, there are three main undesirable drawbacks. 
Firstly, as the price comparison is done manually, maintaining a large wrapper 

Gray Cary\SF\3098970.2 -2- 
2102680-991000 



repository becomes very costly, particularly in view of the continuing growth of the 
Internet. Secondly, great effort must be invested to keep the price and other information 
up-to-date. Lastly, the size of the database required to store and coordinate all of the 
above information is extremely large. 
5 The real-time hard-coded wrappers approach is an alternative to the non real- 

time approach. Instead of fetching the items directly as in the non real-time approach, 
the real-time approach tries to generalize the HTML page into a specific format. To 
perform this extraction task, a customized wrapper procedure named pcwrapHLRT — 
programming acronym— is invoked. Figure 1 provides an example of the pertinent 

10 portion of the program that has one "while" loop. In this example, the algorithm behind 
the creation of a wrapper is to confine the target data on the HTML page by a pair of 
delimiters. The pcwrapHLRT procedure works because the site exhibits a uniform 
formatting convention. Product items are rendered in bold whereas prices are in italics. 
PcwrapHLRT operates by scanning the HTML document for particular strings {"<B>, 

15 "</B>, "<l>," "</l>"} that identify the text fragments to be extracted. These strings are 
identified by pcwrapHLRT as l h r if / p and r p , respectively. The notation / k (ke {i, p}) 
indicates that the string delimits the left-hand edge of an attribute to be extracted 
whereas r k indicates a right delimiter. Other possible attributes to be extracted by a 
wrapper are product names, graphics, terms and conditions, etc. 

20 When a HTML page is given, pcwrapHLRT sequentially scans the entire page 

starting from the head line number. The outer loop checks whether there are additional 
model numbers and/or price pairs to extract by searching for delimiter "<B>" on the non- 
scanned portion of the page. As long as the beginning of a model number is found, the 
inner loop is invoked to extract the appropriate page sub-strings. 

25 Few Websites publish their formatting conventions. Thus, the designer of an 

information-gathering system using pcwrapHLRT would manually construct such a 
wrapper for each resource. Unfortunately, this hard-coding process is tedious and 
error-prone, as a common HTML page may consist of several thousand lines of code. 
Moreover, most sites periodically change their formatting conventions that usually will 

30 break a wrapper. 
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Another disadvantage of pcwrapHLRT is that the speed of search time is 
moderate, as the agents have to contact the vendor Website upon receiving a request 
from the user. Because this kind of wrapper is partially automated, extra administrative 
work must be performed to manually analyze the format of the HTML page in order to 
5 determine the wrapper. 

SUMMARY OF THE INVENTION 
In view of such commonly encountered afore-mentioned problems, an alternative 
to manual and partially automated manipulation, based upon a new Internet strategy, is 
automatic manipulation — online intelligent price comparison agents that can relieve the 

10 price comparison process of online catalog buying or shopping, (auctioning, etc.), and 
can meanwhile provide a better navigational environment with an Internet-friendly 
interactive-agent-character graphical user interface (IACGUI). This will be particularly 
useful when the so-called 4th Generation Global Ensemble Marketplace Framework — 
agent-mediated B-to-C, C-to-C, B-to-B e-procurement and auction, G-to-B/C 

15 (Government-to-Business/Consumer) tendering e-commerce and m-commerce (mobile 
commerce) — becomes widely implemented. Thus, the system of the present invention 
provides a better environment for consumer-to-business transactions. 

To put it simply, online intelligent price comparison agents are automated online 
buying or shopping assistants that scour global online multilingual stores and ferret out 

20 deals on every product. They also deliver value-added (customer rated) Business-Web 
services to the online buyer / user. Such agents are attractive because they can 
relieve users of the tedium of manually carrying out every operation in the Consumer 
Buying Behavior model. 

Conventionally, a buyer / user communicates with a Web server of an online 

25 service through the interface at the front-end, which presents a form completed by the 
buyer / user for entering the terms to be searched. Once the buyer / user submits the 
search request, the online service's Web server queries its database for matches, and 
presents the results to the user's Web browser. 

In the present invention, user agents (online intelligent price comparison agents 

30 acting on behalf of the human buyer / user) in the online catalog price comparison 
process carry the terms and keywords to be searched for, and communicate with 
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numerous multilingual Web servers of any of the 246 Internet-connected countries over 
inter-connected computer networks on the World Wide Web for the buyer's / user's best 
interests. The user agent then ranks the online vendor sites it finds and presents a 
summary of search results via the Web browser to the online human user. 
5 The advantages of applying the system of the present invention to multiple e- 

commerce segments are very significant. Communication efficiency and effectiveness 
can be increased considerably, and time and cost-savings for online vendors as well as 
online buyers can be maximized. Most importantly, the user / buyer will have access to 
an unprecedented and countless number of sources of information and a myriad of 

10 products sources on a global scale, as well as an immeasurable number of business 
opportunities. The system and method of the present invention will also help to collapse 
time and languages barriers, demographic boundaries, and truly enable the 
globalization of e-commerce. Besides, the personalized, continuously running, 
autonomous nature of the user agents makes them well suited for mediating buyer/ 

15 consumer behaviors. It is believed that the present invention will help to optimize the 
whole buying experience and revolutionize current e-commerce. 

Reference is made to US Patent Application Number 09/967,233, filed on 
September 27, 2001, which is incorporated herein by reference in its entirety, and 
portions of which are reproduced herein. 

20 Described in the referenced US Patent Application Number 09/967,233 is a 

method and system which provides a worldwide online shopping portal that enables 
online users to buy/shop across national boundaries and in multiple languages. It has 
been found that a Java implementation of the system is particularly advantageous, in 
part because such implementation has increased compatibility with user and 

25 infrastructure systems, as well as decreases the vulnerability of the system to 

unauthorized intrusions. An implementation of the system for mobile users has been 
created and is described herein. The mobile implementation preferably uses the J2ME 
and kXML platforms, and features a simplified set of steps which have been adapted to 
the more limited resources available in mobile equipment. Also described is an 

30 enhanced information extraction methodology that permits more precise identification of 
the information being sought by the system. 
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It is therefore an object of the present invention to provide an improved price 
comparison of online vendors' products or services. 

It is yet another object of the present invention to construct vendor descriptions of 
the online shop. 

5 It is yet another object of the present invention to collect data, including sample 

products and URLs, which are used for training. 

It is yet another object of the present invention to retrieve training data before 
performing learning of vendor sites or online shops. 

It is yet another object of the present invention to collect training pages from 
10 online vendors using information given in the training data. 

It is yet another object of the present invention to generate vendor descriptions 
from the training data and collected training pages. 

It is yet another object of the present invention to store the generated vendor 
descriptions in an offline database. 
15 It is yet another object of the present invention to provide an interface for a 

system administrator to add, modify and delete vendors supported by the system. 

It is yet another object of the present invention to provide an interface for an 
administrator to view vendor information. 

It is yet another object of the present invention to provide a price comparison 
20 method whereby a customer can initiate the price comparison. 

It is yet another object of the present invention to parse HTML pages into useful 

data. 

It is yet another object of the present invention to provide filtering and sorting of 
desired products / services. 
25 It is yet another object of the present invention to provide a single interface to 

compare prices of different online multilingual vendors and different domains on the 
Internet or World Wide Web. 

It is still another object of the present invention to provide a mobile user 
implementation of the system and methods, and in particular to provide an interface 
30 accessible by mobile users to compare prices of different online multilingual vendors 
and different domains on the Internet or World Wide Web. 
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The mobile user implementation of the present invention provides a simplified 
interface preferably using the J2ME and kXML platforms to communicate with the 
underlying search system as described herein. 

A first user agent is embodied in the system of the present invention, and is 
5 implemented in the form of a Semantics Recognition Learner Agent (SRLA). It 

conducts a real-time autonomous wrapper induction using an inductive learning method 
to learn the URL of a vendor's site and its domain description, and generalized rules 
about the organization of the vendor's site based upon previously compiled or prepared 
training examples provided by the system administrator. (In one embodiment, the 

10 SRLA connects a Microsoft brand back-end SQL-compliant server or Microsoft Access 
database to produce a vendor and products description only once per online store.) 
The wrapper induction is done by constructing in real-time a wrapper of examples that is 
extracted from vendor and products descriptions stored in the offline database. Then 
with the examples, the SRLA autonomously zaps through the Internet in real-time to the 

15 remote host of the vendor site to access the Web pages exhibiting the specified 

examples according to the URL provided, then intelligently fills-in a relevant search form 
with the domain or product information, and then virtually "presses enter" to thereby 
submit a search request to the site. Result pages that are returned in response to the 
search criteria are either a successful page containing accurate information or a failure 

20 page. These result pages, having vendor and products descriptions that are unique to a 
particular vendor (either a registered or non-registered vendor with the system), are 
consequently stored in a vendor description list in the offline database (such as in an 
SQL-compliant server or Microsoft Access database) maintained by the system 
administrator. Vendor URLs, vendor descriptions and other information, are preferably 

25 automatically updated once daily on schedule. 

A second user agent embodied in the system of the present invention is referred 
to as a Semantics Recognition Buyer Agent (SRBA). The SRBA uses the vendor 
descriptions previously "learned" by the Semantics Recognition Learner Agent to search 
for a match while accessing simultaneously various online multilingual vendor sites on 

30 the World Wide Web. The SRBA intelligently fills-in a vendor's search form with the 
product information provided by an online buyer or user and virtually "presses enter." 
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The vendor then returns search result pages to the SRBA through the World Wide Web 
in such a manner that result pages arrive at about the same time as other ones being 
returned from other vendors. (The Semantics Recognition Buyer Agent stores these 
returned pages in a separate memory or cache location as hits for later use by other 
5 SRBAs.) The SRBA analyzes the returned pages according to the corresponding 
vendor descriptions, extracts from them relevant information and data, sorts prices and 
model numbers, and displays them in a formatted summary on the screen of a client- 
machine via a Web browser to the online buyer / user. 

In accordance with the present invention, a method is provided for a computer- 

10 implemented Semantics Recognition Learner Agent to perform an inductive learning. 
The method comprises retrieving training data specific to an online vendor to generate a 
corresponding vendor description from inter-connected computer networks. The method 
comprises collecting training pages using the given training pages using the given 
training data stored in the vendor list. Using the training data as well as the retrieved 

15 training pages, the method comprises an inductive learning method to generate a 
vendor-specific vendor description from information that is extracted from the training 
data and retrieved training pages. 

A method is provided for storing the retrieved and/or extracted vendor 
descriptions in an offline database that will be later used by a Semantics Recognition 

20 Buyer Agent (SRBA). 

A method is provided in accordance with the present invention for price 
comparison of products or services from online vendors. The method comprises an 
online user initializing a request for a specific product or service, then a Semantics 
Recognition Buyer Agent constructs parameters of a search request using pre-defined 

25 vendor descriptions. The method comprises posting requests to different online 

vendors, preferably at the same time, extracting data from result pages returned from 
the online vendors using a parser that comprises the vendor descriptions. The method 
comprises constructing/composing sorted and filtered data by a Semantics Recognition 
Buyer Agent in a HTML format for presenting the data to the online buyer / user. 

30 A method is provided and implemented through the Semantics Recognition 

Buyer Agent for parsing returned pages from online vendors to retrieve useful data. The 
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method comprises retrieving vendor descriptions from an offline database, parsing the 
returned page from online vendors for any of the (currently 246) Internet-connected 
countries on the World Wide Web, and collecting useful data using information from the 
returned vendor descriptions. 
5 In one embodiment of the invention, the above functionality is only available on 

member Web pages after an online buyer signs up as a registered temporary trial or life 
member. 

In accordance with the present invention, a method is provided for real-time 
online search processing of selected types of information over inter-connected 

10 computer networks. The method comprises a number of steps: assembling site 

descriptions for a plurality of sites in the inter-connected computer networks including 
for each of the plurality of sites (a) a URL for the site; a search form URL for the site; (b) 
generalized rules of how the selected types of information on the site is organized; (c) 
sample data retrieved from the site corresponding to the selected types of information; 

15 and (d) descriptions of domains found on the site; receiving a request for specified 
types of information from an online user; identifying from the site descriptions, sites 
which may have the specified types of information; constructing search requests for the 
specified types of information using the site descriptions for each identified site; 
submitting the constructed search requests to the identified sites; receiving search 

20 results from the identified sites, and upon locating accurate matches in the received 

search results, extracting information corresponding to the specified types of information 
in a native language of the site, and displaying the extracted information to the user. 

More generally, the present invention involves a method for real-time online 
search processing over the inter-connected computer networks. The method comprises 

25 the steps of: (a) maintaining in an offline database information for a plurality of vendor 
sites from the inter-connected computer networks; the information includes URLs, 
search form URLs, description of domains, and vendor descriptions, wherein the vendor 
descriptions include generalized rules about how product information is organized on 
each of the vendor sites; (b) processing parameters for a price comparison request for a 

30 desired product using the information maintained in the offline database, while the price 
comparison request is received from an online user and/or the Semantics Recognition 



GrayCary\SF\3098970.2 
2102680-991000 



Buyer Agent; (c) extracting real-time price and product information from identified ones 
of the plurality of vendor sites, wherein the extracted price and product information are 
in a native language of the site; and (d) displaying the extracted price and product 
information to the user. 

5 DESCRIPTION OF THE DRAWINGS 

Figure 1 is an example of the pertinent portion of the pcwrapHLRT program used 
in a prior real-time hard-coded wrappers approach for retrieving information from a 
vendor's Website. 

Figure 2 is a generalized diagram illustrating the interaction between a preferred 
10 embodiment of the present invention, user agents of the present invention, a user / 
buyer, and online vendors, by way of the World Wide Web / Internet. 

Figure 3 is a simplified flowchart 100 of an overview of how the Semantics 
Recognition Learner Agent (SRLA) works with training data to generate a vendor 
description. 

15 Figure 4 provides a description of the kinds of information that can be included in 

a vendor description in accordance with the present invention. 

Figure 5 provides an example of data that can populate the vendor description 
fields in accordance with the present invention. 

Figure 6 is a flowchart 200 of an overview of how the Semantics Recognition 
20 Learner Agent (SRLA) performs inductive learning and generates a generalized cross- 
page valid vendor description. 

Figure 7 provides an example of an alignment's portion of a page from a Website 
as it would appear to a person browsing that page on the Internet, and the 
corresponding HTML codes that are used to generate or define such alignment. 
25 Figure 8 provides an example of the labels that, in accordance with the present 

invention, are used to identify the locations of item description and price information in a 
training page. 

Figure 9 is a generalized description of what is represented by the labels used 
during the training procedure of an example of the present invention. 
30 Figures 10A and 10B provide examples of possible delimiter candidates in the 

example of the training process illustrated in Figures 5 to 9. 
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Figure 1 1 is a simplified depiction of a Web page's screenshot having 
Navigational Regularity with a searchable index and product domain fields for easy 
access to a specific inquired database in accordance with the present invention. 

Figure 12 provides a simplified depiction of a screenshot of a Web page that 
5 illustrates the use of Uniformity Regularity with all items typically laid out in a simple 
consistent format. In the page is a frame, and the frame contains the search results of 
the information inquired about, which results are formatted uniformly. 

Figure 13 is a simplified depiction of the same screenshot, as shown in Figure 
12, that illustrates the use of Vertical Separation Regularity with the search results 
10 displaying aligned catalogs of products which are positioned in the center between the 
head and tail. 

Figure 14 is a generalized illustration of the operation of the Semantics 
Recognition Learner Agent of the present invention. 

Figure 15A is a screenshot that displays the search results for the keyword 
15 "electronics" on the vendor site "www.800.com," in which each product is summarized in 
a brief introduction of its features and functions (left and center of the aligned frame) 
and the relevant "List Price" and "Your Price" information appear on the right side of the 
aligned frame, and which information the intelligent price recognizer of the Semantics 
Recognition Learner Agent of the present invention can distinguish during the learning 
20 process of the vendor descriptions. 

Figure 15B is a generalized illustration of the operation of the Semantics 
Recognition Buyer Agent of the present invention that accessed the vendor site 
"www.800.com" at a time after the learning process of vendor descriptions, as shown in 
Figure 14, such that vendor logo's design has subsequently changed to the one as 
25 exhibited in Figure15B. 

Figure 15C is a flowchart 300 of an overview of how the Semantics Recognition 
Buyer Agent (SRBA) 20 in Figure 2 interacting with a vendor description to respond to 
an online buyer's / user's request for price comparison for one, up to all, available online 
multilingual vendors. 

30 Figure 16 is an example of an Interactive-Agent-Character Learner Interface 

screen that can be used to obtain training information for use in the present invention. 

Gray Cary\SF\3098970.2 -11- 
2102680-991000 



Figure 17 is a provided example in which training information has been filled-in 
for the vendor "1 cache.com." 

Figure 18 is an illustration of a the Learner interface screen that can be used to 
display vendor description information which has been learned. 
5 Figure 19 is a screenshot of the Learner Interface with the labeled tab "vendor 

information" through which vendor information can be entered or searched for. 

Figure 20 provides a screenshot of the Learner Interface for displaying the 
Training Examples previously entered for a particular vendor. 

Figure 21 is a screenshot of a Learner Interface which is displayed in response to 
10 opening a file called "Vendor Description." 

Figure 22 illustrates the selection of learning options in accordance with the 
present invention, namely, the "Learn One" option is shown selected, and the vendor's 
name, which has been filled-in, is "1cache.com." 

Figure 23 exhibits the learned results for vendor "1cache.com." 
15 Figure 24 illustrates the wrapper induction problem formulated with the defined 

solution of a simple model of information extraction. 

Figure 25 provides a pseudo-code for the procedure "execHLRT." 

Figure 26 is a module of a simple method in pseudo-code for learning head and 
tail delimiters. 

20 Figures 27A and 27B provide a detailed table and related subroutines for the 

procedure learnHLRT. 

Figure 28 illustrates how the user / buyer communicates with the server to run 
the in-process DLL file (NextGen.dll) on the server machine through an ASP (Active 
Server Page) file (NextGen.asp), in accordance with an embodiment of the present 

25 invention. 

Figure 29 illustrates the manner in which the Semantics Recognition Buyer Agent 
facilitates communication between the user and the database server. 

Figure 30 provides a detailed flow chart of how to set up the SQL server 
database in accordance with one embodiment of the present invention. 
30 Figure 31 is an illustration of how the Semantics Recognition Buyer Agent 

virtually posts a search form to an online vendor site. 
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Figure 32 is a simplified illustration of a "main menu" screen of a GUI or 
Interactive-Agent-Character Shopper / Buyer Interface (IACS/BI) for use with the 
present invention. It is to be noted that there is a choice of "channels" (categories) of 
products provided for the user in the upper right hand corner of this "main menu" 
5 screen. A "Quick Search" feature is also provided in the left hand side of the screen. 
Right beneath it, there is a provided box in which an animated feature of self-typing 
instructs the online human user how to use the quick search option. The left hand 
screen panel also provides a set of boxes for member sign-in as a temporary trial or life 
member. (Note that most of the portal's functions of the present invention are disabled 

10 until the user authentication is validated.) At the bottom left hand corner is provided a 
set of links to online vendors that have been registered with the portal of the present 
invention whereas on the right, it can be observed that a big message box labeled 
"feedback" is provided for the online user to enter a message with comments through e- 
mail to the e-mail server, preferably running the Outlook Express brand e-mail 

15 application of Microsoft Corporation. 

Figure 33 is a simplified illustration of a screen of a GUI or Shopper / Buyer 
Interface for use with the present invention in which companies are displayed in 
response to a "Government-to-Business" textual icon which has been clicked on the 
previous screen (not shown) by the online buyer / user. However, note that this very 

20 screen cannot function because these companies, or so-called Government-to- 
Business e-commerce service or platform providers currently restrict strictly for 
member's privilege the access to their Web servers' databases by incorporating an 
authentication security interface in entirely closed-connected computer networked 
environment. 

25 Figure 34 is a simplified illustration of a screen display of a GUI or Shopper/ 

Buyer Interface for use with the present invention in which details are provided about a 
company selected by the user from among the choices provided after the user has 
clicked the "Advanced Search" option on the screen of Figure 33. Note that on this 
screen, the banner in the frame of the panel just right below the tabs for the five types of 

30 domains, the capitalized message "ADVANCED AGENTS ARE ON!" is observed. 

Besides, at the bottom of the screen, the user is provided with dialog boxes which can 
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be filled-in for running a search using the Semantics Recognition Buyer Agent 
functionality provided by the present invention. Again, however, note that this very 
screen cannot function because this company, or so-called Government-to-Business e- 
commerce service or platform provider currently restricts strictly for member's privilege 
5 the access to their Web server's databases by incorporating an authentication security 
interface in entirely closed-connected computer networked environment. 

Figure 35 is a simplified illustration of a screen of a GUI or Shopper / Buyer 
Interface for use with the present invention in which companies are displayed in 
response to "Business-to-Business" textual icon which has been clicked on a previous 

10 screen (not shown) by the online buyer / user. However, note that this very screen 
cannot function because these companies, or so-called Business-to-Business e- 
commerce service / platform providers currently restrict strictly for member's privilege 
the access to their Web servers' databases by incorporating an authentication security 
interface in entirely closed-connected computer networked environment. 

15 Figure 36 is a simplified illustration of a screen display of a GUI or Shopper / 

Buyer Interface for use with the present invention in which details are provided about 
companies selected by the user from among the choices provided after the user has 
clicked the "Advanced Search" option on the screen in Figure 35. 

Figure 37 is a simplified illustration of a screen of a GUI or Shopper / Buyer 

20 Interface for use with the present invention in which selected items and their 

descriptions are displayed in response to the user selecting the "Domain A" tab on the 
screen. 

Figure 38 is a simplified illustration of a screen display of a GUI or Shopper / 
Buyer Interface for use with the present invention in which vendors that are listed sell 
25 items in Domain A in response to the user who has clicked "Advanced Search" option 
on the screen in Figure 37. 

Figure 39 is a simplified illustration of a screen display of a GUI or Shopper / 
Buyer Interface for use with the present invention in which details are provided of the 
results of a search conducted using the Semantics Recognition Buyer Agent's feature of 
30 the present invention. The Shopper / Buyer Interface responds to the user submitting a 
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search request through the search parameters interface as shown at the bottom of the 
screen in Figure 38. 

Figure 40 illustrates the Main Page of the user interface as it may appear on a 
desktop or laptop or other display for an embodiment of the present invention. 
5 Figure 41 illustrates the Main Page of the user interface as it may appear on a 

desktop or laptop or other display when the user selects a country where vendors of 
interest are located for an embodiment of the present invention. 

Figure 42 illustrates a Results Page containing the results of a search for a 
keyword in an embodiment of the present invention. 
10 Figure 43 illustrates the Advanced Search page of an embodiment of the present 

invention. 

Figure 44 provides a flowchart that depicts the detailed application logic of 
Shopper/Shopping Agents in accordance with and embodiment of the present invention. 

Figure 45 depicts the detailed application logic of Learner Agent in accordance 
15 with an embodiment of the present invention 

Figure 46 provides information about the country information fields maintained by 
an embodiment of the present invention. 

Figure 47 illustrates the process for adding country information in accordance 
with an embodiment of the present invention. 
20 Figure 48 illustrates the screen provided at the Administration Console listing 

Countries in the database in accordance with an embodiment of the present invention. 

Figure 49 illustrates the screen which appears on the Administration Console in 
connection with editing country information in the database. 

Figure 50 illustrates the screen which appears on the Administration Console in 
25 connection with adding country information to the database. 

Figure 51 provides information about the vendor information fields maintained by 
an embodiment of the present invention. 

Figure 52 illustrates the process for adding vendor information in accordance 
with an embodiment of the present invention. 
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Figure 53 illustrates the Administration Console screen that appears when the 
Vendor link is clicked in the upper right hand corner of the Console in accordance with 
an embodiment of the present invention. 

Figure 54 illustrates an example of a screen which appears on the Administration 
5 Console following an operation to retrieve vendors for a given specific locale, in this 
example, the United States in accordance with an embodiment of the present invention. 

Figure 55 illustrates Existing Details for a vendor that appears in a Vendor 
screen/page of the Administration Console in accordance with an embodiment of the 
present invention. 

10 Figure 56 illustrates the screen which appears on the Administration Console in 

connection with editing vendor information in the database in accordance with an 

embodiment of the present invention. 

Figure 57 provides an example of the screen that is displayed in the Add Vendor 

operation in accordance with an embodiment of the present invention. 
15 Figure 58 illustrates the Add Training Example screen which is used for operator 

input for a new training example in accordance with an embodiment of the present 

invention. 

Figure 59 is an illustration of the Edit Vendor Description screen in accordance 
with an embodiment of the present invention. 
20 Figures 60A and 60B illustrate a select country operation in the mobile 

implementation of the present invention. 

Figures 61 A, 61 B, 61 C, 61 D, 61 E, and 61 F illustrate a keyword search operation 
in the mobile implementation of the present invention. 

Figure 62 illustrates the model used for the Select Country function of a mobile 
25 implementation of the present invention. 

Figure 63 illustrates the model used a mobile embodiment of the present 
invention for searching for an item. 

Figures 64A, 64B, 64C, 64D, 64E, 64F, and 64G illustrate the appearance of the 
main screen in an emulation of a mobile handheld device screen in a mobile 
30 embodiment of the present invention. 
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Figure 65 is an illustration of the "Learning in Progress - Please Wait" screen 
which appears while the Learner is accessing a vendor site to learn the various 
wrappers used in the site. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
5 Referring to Figure 2, a generalized diagram is provided illustrating the 

interaction between a preferred embodiment 10 of the present invention, a user / buyer 
12, and online vendors 14, byway of the World Wide Web / Internet 16. 

In the preferred embodiment 10 of the present invention, a Learner Agent 18 
(also referred to as a Semantics Recognition Learner Agent) and a Shopper Agent 20 

10 (also referred to as a Semantics Recognition Buyer Agent) are provided. A server 22 is 
employed to provide access to an offline database 24 that stores global multilingual 
vendor information. A system administrator 26 prepares/compiles training data about 
selected vendor sites and stores them in a "vendor list" 27 in offline database 24 
through server 22. The system administrator 26 can then employ the training data and 

15 the Semantics Recognition Learner Agent 18 to conduct "inductive learning" from 
training pages retrieved from vendor sites by way of the World Wide Web 16. The 
"inductive learning" results in vendor descriptions in the form of vendor description list 
28 which are stored in the offline database 24. 

A user / buyer 12 can use the preferred embodiment of the present invention to 

20 retrieve designated information about designated subjects by using Semantics 

Recognition Buyer Agent (SRBA) 20. The SRBA 20 processes a request from the user 
/ buyer 12 by using information contained in the previously learned vendor descriptions 
28. The information in the vendor descriptions 24 permits the Semantics Recognition 
Buyer Agent 20 to instantly prepare and issue searches on many vendor Websites 

25 substantially simultaneously by way of the World Wide Web 1 6. The vendor 

descriptions also permit the Semantics Recognition Buyer Agent 20 to instantly process 
received search results, and to present to the user / buyer 12 the results of the search 
from all vendor sites searched which have been filtered of extraneous and irrelevant 
information. 

30 Referring now to Figure 3, flowchart 100 illustrates the operation of an 

embodiment of the present invention of the Semantics Recognition Learner Agent 
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(SRLA) 18. In the preferred embodiment of the present invention, the Semantics 
Recognition Learner Agent 18 is embodied in a computer program running on a server 
or personal computer. In step 110, the Semantics Recognition Learner Agent 18 
retrieves pre-defined or earlier-prepared training data from the "vendor lists" 27 stored in 
5 the training database 24. The training database 24 is preferably offline. 

The training data includes a bundle of data pertaining to the online vendors from 
which information is to be learned. These data may include URLs, domain descriptions, 
sample products and attributes and other domain-specific information as shown below 
in the right column: 



Vendor's Name 


1cache.com 


Vendor's URL 


http://www.cache.com 


Vendor's Search Form 
URL 


http://st4.yahoo.com/cgi- 
bin/nsearch?catalog=1cache&query= 


Learning Domain 


dvd 


Training Examples 


i) . DVD Virtual Notebook Theater with l-Glasses 

ii) . JVC XV523GD Dolby Digital DVD Player 

iii) . Pioneer DVL -919- Combination LC/DVD/CD Player 



Figure 4 provides an example of the types and description of name labels of 
trained or "learned" data in accordance with the present invention. Figure 5 is the 
illustrated example of the table for the learned actual "data elements" which have been 
generated during the vendor descriptions learning process for Figure 4, and are stored 
15 in the vendor description list in the offline database, and maintained by the system 
administrator 26. 

The "trained" data is preferably stored in an SQL-compliant or a Microsoft 
Access database. This adds extra extensibility to the selection of the data container 
from different vendors. Typically, the trained data is independent of the product domain, 
20 written characters and presentation style of the online vendor. One exception is the 
URL path in the trained data, which is required to uniquely identify different vendors. 

Returning to Figure 3, in step 120 a check is imposed to see if more vendors are 
required to be learned by the Semantics Recognition Learner Agent 18. If there are 
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vendors pending to be learned, the Semantics Recognition Learner Agent 18 will 
proceed to step 130; otherwise, the learning session terminates. In step 130, using the 
pre-defined training data, the Semantics Recognition Learner Agent 18 intelligently 
accesses specified online vendors to which the pre-defined training data corresponds. 
5 For each of the specific products specified in the training data, the Semantics 

Recognition Learner Agent 18 searches the specific product via the searching feature of 
the vendor's site. Typically, the Semantics Recognition Learner Agent 18 retrieves 
several pages of training data to be learned from the system of the present invention or 
from manual input of the system administrator, which are called "training pages," and 
10 which will later be used to perform inductive learning. In the preferred embodiment, 
control data (training data to induce error pages in the vendor sites) is also included in 
this phase. 

Next, in step 140, the computer program performs an inductive learning on the 
training pages obtained by the Semantics Recognition Learner Agent 18. The objective 

15 of the inductive learning is to obtain a generic description of the site and how it 

organizes the product data and logically presents the product data to a potential online 
customer. The product of this learning is called a "vendor description" 28 — this phase 
will be further described and explained in accordance with Figure 6. 

Then, in step 150, the Semantics Recognition Learner Agent 18 stores the 

20 learned result preferably in an SQL-compliant or Microsoft Access database 24. (The 
vendor information or "vendor descriptions" 28 stored in offline database 24 will later be 
used by the online Semantic Recognition Buyer Agent 20.) Following the completion of 
the storing step 150, the Semantics Recognition Learner Agent 18 returns to the step 
120 to see if there are more vendors to be learned. If so, steps 130 through 150 are 

25 repeated. Otherwise, the learning process terminates. 

Vendor Description Learning Process 

Referring now to Figure 7, the vendor descriptions learning process will be 
explained in further detail using is a simple model of information extraction, and a 
simplified training page example. The left hand side of Figure 7 shows the alignment of 
30 model and price information as it appears to a potential customer browsing a vendor 
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site. The right hand side of Figure 7 shows the HTML coding which generates the 
alignment. For example, the first three (3) lines on the right hand side identify the 
coding as HTML, provide the name of the alignment— "A Simple Product Catalogs," and 
indicate the start of the information to be displayed. Line four (4) provides the text for 
5 the title of the table— "MD PRICE." Lines six and seven (6,7) provide the text for the 
names of the columns, "Model Number" and "PRICE (US$)," respectively. Lines eight 
through eleven (8-11) provide model number and price information. The remaining lines 
identify such information as the end of the table, the alignment of the table, and the end 
of the body of the Product Catalog. 

10 Firstly, a wrapper function generates a set of "labels" for the given training page. 

A label is used to identify the location of information for the training products in the 
training page. Figure 8 illustrates for the simple product training page of Figure 7, a set 
of labels generated by the Semantics Recognition Learner Agent 18. The "labels" in 
Figure 8 indicate that the simple product catalogue page of Figure 7 contains four (4) 

15 "tuples," where each tuple consists of an "item" value and a "price" value. A pair of 
integers represents each value. 

Consider the first pair, <174, 180>. These integers indicate that the attribute of 
the first tuple is the sub-string between position 174 and 180, i.e. the string 'HM381MD' 
is located between position 174 and position 180. As used in this example, position 

20 means the number of characters from a designated beginning point, such as the 
beginning of a page, or the end of the "head" of a page. Spaces between text 
characters are counted as a character position. Inspection of the Figure 7 reveals that 
the letter "H" in the string "HM381MD" occurs 174 character positions from the "<" 
character in the first line; and that the "D" in that string occurs at character position 180. 

25 Similarly, the last "tuple" or pair of integers, <356, 361 >, indicates that the last attribute's 
price occurs between character positions 356 and 361 and identifies the string "399.95." 
It is to be understood that while character position is used in this example to identify 
"labels," other criteria can be used within the spirit of the present invention. Other 
criteria can be used with the methodological application of the present invention. For 

30 example, inspection again of Figure 7, consider that the Semantics Recognition Learner 
Agent 18 of Figure 2 autonomously assigns values to the model number and "Your 
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Price" for the four electronics products — while it expresses them as set forth in the 
following formula: 



Model Number 



Price ($US) 



<bij, eu> <bi, p , ei, p > 
< b 2 ,i, e 2 ,i>, <b2, P) e 2iP > 
< b 3 ,i, e 3 ,i>, <b3, P> e 3 , p > 
<b 4 ,i, e 4 j>, <b 4 , P , e 4 , p > 



HM381MD 



MD2070 



MD203 



MDR3 



249.95 



399.95 



599.95 



399.95 



5 



Thus 



, if "b" stands for beginning and "e" stands for ending, then values identifying 



the positions of the second tuples comprise string b_,i, which is the value of the 
beginning of the model number, "M," whereas string e_,i is the value of the ending of the 
model number, "0." Analogically, it is to be understood that the present invention 
enables the automation of the labeling by invoking a modular heuristic search based 

10 upon a standard relational data model comprising an "Item Recognizer" and an 

"Intelligent Price Recognizer" in which, reiteratively, a tuple is a vector <b2,i, b2,p> of 
two strings. String b_,i is the value of item attribute, and string b_,p is the value of price 
attribute. So, attributes represent columns whereas tuples represent rows. The 
numeric value "b2J" between the "b" and the ,"" connotes a position on the second 

15 row— the computation of positional values (labeling) are hence performed in real-time, 
automatically, on-the-fly during the invocation of efficient learnable wrapper induction of 
vendor descriptions in corroborating to label the entire Ppc (Page of product 
catalogue— a page "P" is the Web page containing the desired information) regardless 
of whether the Web pages formatted on the vendor site (in this example, www.800.com) 

20 are in native character strings of any language, or in natural language or coded in 
HTML, XML, cXML, Java, etc. 

The labeling of the content of a training page is represented more generally in 
Figure 9. In the first column, the information being labeled is identified — in this 
example, product and price are the information being sought. In the second column, the 

25 "labels" are identified to which the "tuple" entries correspond— <PRODUCT LEFT 
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DELIMITER, PRODUCT RIGHT DELIMITER> and <PRICE LEFT DELIMITER, PRICE 
RIGHT DELIMITERS 

After the system administrator has executed the learning system once, it then 
retrieves the training page from the vendor list in the offline database in compiling a set 
5 of possible delimiter candidates in parallel with the compilation with the possible sets of 
delimiter candidates in Figures 10A and 10B. And continually, it uses another set of 
training page in contemporaneously performing automatically (labeling) computation in 
real-time, on-the-fly, containing position values, as shown in the above stated example. 
As the intersection of the two sets of candidates yields a valid candidate set, the 
10 Semantics Recognition Learner Agent 18 then chooses one of the valid candidates as a 
vendor description. 

Referring now to Figure 2, the flowchart 200 illustrates an embodiment of the 
Semantics Recognition Learner Agent 18 of the present invention. The methodology 
makes use of three (3) environmental regularities that govern the layout of product 

15 descriptions provided in shopping Websites which permit the information extraction to 
proceed independently of the domain. The regularities include navigation regularity with 
searchable index, uniformity regularity, and vertical separation regularity. 

As to navigational regularity, online stores or vendor sites are designed to service 
consumer and business buyer inquiries. Thus, almost all online vendors provide a 

20 searchable index for easy access to specific inquired database. Using the searchable 
form of a vendor site enables the Semantics Recognition Learner Agent 18 to 
generalize the formatting fashion of multilingual home and Web pages. Figure 1 1 is a 
simplified drawing depicting a home page with a searchable index and product domain 
fields. 

25 With regard to uniformity regularity, although online stores or vendors differ 

widely from each other in their product description formats, any given online vendor 
typically lays out all item descriptions in a simple consistent format. Figure 12 is a 
simplified drawing of a Web page's screen depicting the layout of search results 
formatted uniformly. Thus, it can be seen that each search result listed begins with a 

30 "model number" string below which is provided a "product description." Besides, a 
"PRICE 1" and a "PRICE 2" are to the right of the "product description." 
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Figure 13 provides the simplified drawing of the same screen for the search 
results that illustrates the use of vertical separation to display catalogs of products. This 
vertical formatting can be classified as the head, content, and tail of the document. 

As originally devised the information infrastructure of the Internet — site 
5 architecture, formatting of online vendor's products description and expression of 
technologies — was intended for use by humans. This is apparent in the use of query 
mechanisms and output standards which are particularly suited for direct human 
manipulation. Online vendors comply with these regularities because they enable 
online sales to human shoppers or buyers. Although there is no guarantee that what 
10 makes an online store easy for humans to navigate will make it user-friendly for an 
intelligent software agent to master, the system — online intelligent information 
comparison of multilingual electronic data sources — of the present invention is designed 
to take advantage of these regularities. 

In accordance with the present invention, wrapper construction is implemented 
15 through an inductive learning process. The methodology learns a vendor's wrapper by 
reasoning about a sample of the vendor's Web pages. In the methodology of the 
present invention, instances correspond to the vendor's pages, a page's label 
corresponds to its relevant content, and hypotheses correspond to the constructed 
wrappers. 

20 Besides, in accordance with the present invention, an efficiently learnable 

wrapper class, such as the HLRT wrapper class, is incorporated. 

Furthermore, in order to make sure that the methodology performs well, noise- 
tolerant techniques are employed when training data exhibit high levels of noise. For 
instance, given the screenshot example ofwww.800.com in Figure 15A, an intelligent 

25 price recognizer can distinguish between "List Price" and "Your Price." The recognized 
instances are then corroborated to label the entire page. Consider a recognizer for 
items and another for price, corroboration produces a Label methodology that labels 
pages containing pairs of these attributes. 

In effect, vendors attempt to create a sense of identity by using a uniform look for 

30 all types of products. To exemplify, a vendor presents an MD product information in the 
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same format as a DVD product. By taking advantage of this regularity, every product is 
assumedly described in the same format. 

The Semantics Recognition Learner Agent 18 in Figure 2 learns a wrapper only 
from a specific domain of examples and attempts to fit this domain to all other domains 
5 (all other product categories in entirely different ontological terms) organized in 

consistent format and catalogued online on all the rest of Websites in the 245 Internet- 
connected nations on the World Wide Web. Thus, it is feasible for the Semantics 
Recognition Learner Agent 18 in Figure 2 of the present invention to maintain a 
thoroughly updated nomenclature of a global products databank without writing code 

10 onto modules of a SQL-compliant database nor manually entering each product in every 
domain onto a Microsoft Access database. 

Continuing with Figure 6, in step 210, the Semantics Recognition Learner Agent 
1 8 generates a set of labels to represent the content of the training page. Stated in 
another way, the methodology of labeling position values is to identify the location of 

15 information for the training products in the training page. Again, the Semantics 

Recognition Learner Agent 18 in Figure 2 automatically generates labels in real-time on- 

the-fly containing position values as follows: 

' <bi, if ei,i>, <b 1iP , ei iP > 
_ <b 2 ,i, e 2 ,i>, <b 2 ,p, e 2 , P > 
<b3,i, e 3 ,i>, <b 3 ,p, e 3 , p > 

20 

| <b4,i, e 4 ,i>, <b 4 ,p, e4, p > 

For further detail, see the right-hand column in Figure 8. 

In step 220 the Semantics Recognition Learner Agent 18 performs inductive 
learning on the retrieved training pages using the associated labels to output a set of 

25 possible "vendor description" candidates. Since the candidates are generated from a 
particular training page with specific training data, there is no way the candidates can be 
invalid for those pages. However, if the candidates are to be valid throughout the 
vendor's entire site, a cross page validation should be performed to derive a 
generalized vendor description which will be valid across the vendor's site. 

30 In step 240, a vendor description validator (VDV) validates a possible vendor 

description candidate against another set of training pages (retrieved in step 1 30, Figure 
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3). If a vendor description is satisfactory, the learning process will stop, see step 250, 
otherwise the validation process will continue to refine the vendor description selection 
by using the rest of the candidates and looping back through steps 230, 240 and 250. 
One criteria for a "satisfactory" vendor description is that the candidates for each 
5 subsequently analyzed training page are the same in number and character as for the 
previous training page. If a subsequently analyzed training page has a different number 
of candidates, then another training page should be analyzed. 

Figures 10A and 10B provide as examples of vendor description candidates left 
and right delimiters for the Item description, the Price information, the Head, and the 
10 Tail of a training page. An example of a "vendor description" is provided in Figure 5, 
which includes delimiters identified for the Head, Tail, Item, and Price information of an 
example page. 

Training data for use with a particular vendor is preferably compiled by the 
system administrator 26. As will be described in further detail herein, to add a specific 

15 vendor to the system of the present invention, the vendor's name, vendor's URL, submit 
form's URL, domain data for the corresponding training examples are provided and 
stored in the offline database 24, which can be, for example, a Microsoft Access 
database. The vendor's name will be the primary key of a record. Manual wrapper 
input can be provided as an option. In order to provide an accurate set of data for the 

20 training example, which in turn will greatly enhance the accuracy and efficiency of the 
vendor information learned by the Semantics Recognition Learner Agent 18 in preparing 
itself for generating vendor descriptions in real-time, automatically, on-the-fly, it is 
important that the system administrator, or other individual, who prepares the training 
example data be knowledgeable about Web page URLs, and domain name setup, be 

25 somewhat knowledgeable of the native language used in any multilingual vendor's 
Website being processed, and be able to identify the information types which are 
targeted for learning. This person need not be knowledgeable about coding. 

Once a vendor's information is provided, administrator 26 can run the Semantics 
Recognition Learner Agent process for each vendor. After the administrator has 

30 executed the Semantics Recognition Learner Agent 18 one time for a vendor, he or she 
then navigates through the learning process with a step-by-step walkthrough of the 
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screens of the Interactive-Agent-Character Learner Interfaces (lACLIs) in running any 
desired options as shown in Figures 16 through 23. Ultimately, the result set of "vendor 
descriptions" that are retrieved from returned trained pages, will then be stored in the 
offline database 24, such as a Microsoft Access database. To delete/remove a specific 
5 vendor, the administrator may delete the record directly from "vendor list" or "vendor 
description list." To modify/edit a specific vendor, the administrator may modify the 
record from the "vendor list" or "vendor description list" in the database. 

In a nutshell, the Semantics Recognition Learner Agent 18 of the present 
invention generates a vendor description that is unique to a particular vendor. The 

10 vendor description is the set of generalized rules of how a vendor organizes its product 
information in a specific format. Hence, the input to the wrapper construction system of 
the present invention is essentially a sample of the behavior of the wrapper to be 
learned. Under this formulation, wrapper construction becomes a process of 
reconstructing a wrapper based on a sample of its behaviors. 

15 The methodology of the Semantics Recognition Learner Agent (SRLA) 18 is 

summarized in Figure 14 by way of a simplified example. In step 1 , two pieces of 
information are fed into the system in order to conduct the wrapper induction: (1 ) the 
URL of the vendor's Website (e.g. http://www.800.com), and (2) the domain description, 
which contains some of the training examples of that particular domain. For example, a 

20 domain description may be "electronic products," and a record of that domain may be 
"Sony HM381 MD," which is a model number used to fill-in a vendor's search form. In 
steps 2 and 3, the Semantics Recognition Learner Agent 18 automatically goes through 
the Internet to the vendor's Website using the URL and the domain / model number 
from the training examples. For the specific example, the Learner Agent will go to 

25 www.800.com's Web page according to the URL provided in step 1 . Then it will fill-in 
the necessary product information (i.e. domain description — "electronic products" and 
"HM381 MD") in the relevant search form. Finally, it will "submit" the search form to 
request a search and await a response. 

Referring to step 4, a result page is returned according to the searching criteria. 

30 The result may be a successful result page with relevant product descriptions, or may 
be a failure page. It is to be noted that the content of interest in the returned page are 
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the HTML codes, the item description, the item price, and the locations of such 
information with respect to the HTML codes. 

In steps 5 and 6, the search result page is returned by way of the Internet to the 
Learner Agent 18 for analysis. In step 7, the analysis conducted is called "Wrapper 
5 Induction," in which the page is generalized to a set of layout and formatting rules that 
the vendor follows to present its product description in a logical manner. With these 
rules, during the Semantics Recognition Buyer Agent process of the present invention, 
the Buyer Agent 20 may extract product information from the same vendor when a user 
/ buyer is searching for some product information from the same domain on the vendor 
10 site. 

It is to be understood that in accordance with the present invention, the 
Semantics Recognition Learner Agent process will be performed for each vendor from 
which a vendor description is desired. Because of the information delimiter approach 
used by the present invention, vendor descriptions can be obtained from any vendor 

15 sites in any language — concisely, although the language presented to a user might be 
of a particular native character string, the underlying codes which can be identified as 
delimiters for the desired information, remain the same regardless of the native 
character strings of the language. In other words, information of the vendor descriptions 
will be obtained from a vendor site in the native language used by that site. There is no 

20 need for any translation of the native language used into a standard language. 
Moreover, because the delimiter candidates identified for each vendor site are not 
coded in underlying codes of the programming language used for that site, subsequent 
searching can be done without the need for different programming languages used 
among the sites to be searched for. This permits the Semantics Recognition Buyer 

25 Agent 20 to conduct searches on multilingual and multiple domains (product categories) 
bases, and independently of any programming language. 

Referring to Figure 15C, flowchart 300 illustrates an embodiment of the 
Semantics Recognition Buyer Agent 20 of the present invention. In step 310, the Buyer 
Agent 20 receives a request from a buyer / user 12 in Figure 2, who wants a price 

30 comparison for a product. In step 310, the Buyer Agent 20 also preferably establishes a 
connection to the buyer / user 12 with an ActiveX component for the communication. 
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The user 12 must provide at least one parameter that may contain, for instance, the 
desired product name, the range of the desired price, the target online vendor or the 
sorting criteria. Step 312 checks to see if there are any "hits" in memory or cache 
containing the desired information of the identified vendor site; if yes, the Buyer Agent 
5 will go to step 370 for sorting extracted target information. The Buyer Agent will then go 
to step 380 to generate result pages from the target information in HTML, and then in 
step 390, the Buyer Agent will display the result pages to the online human user / buyer. 

If any "hits" are not found in step 312, step 320 will invoke the Buyer Agent 20 to 
use the input parameters to retrieve the vendor descriptions from the offline database 

10 24. These "vendor descriptions" are the ones previously defined by Semantics 

Recognition Learner Agent 18 during the vendor descriptions learning process. In step 
330, Buyer Agent 20 will compose a user's new request to access different online 
vendors identified in the "vendor description list." The composed user's new request will 
be based on the parameters given by the user and the data in the vendor descriptions. 

15 Preferably, if there are N online vendors to whom a request (such as a product model 
request) will be made, there will be N new requests to be composed by the Semantics 
Recognition Buyer Agent 20. 

The Semantics Recognition Buyer Agent 20 uses the vendor descriptions to get 
the price information from the vendor site in real-time. The Buyer Agent 20 uses the 

20 vendor's URL and the vendor's name that are included in the information that makes up 
the vendor descriptions, to navigate to the vendor's site. Also included in the vendor 
descriptions is the search form URL for the vendor. In step 340, after navigating to the 
vendor site, the Semantics Recognition Buyer Agent 20 "virtually" fills-in the vendor 
search form based on the user's new request, and "virtually" presses enter to submit it. 

25 This is done for each of the identified online vendors. 

As mentioned above, the vendor descriptions in the offline database 24 include a 
field that provides information of the vendor's search form URL, such as 
"http://www.onlineshop.com/search. asp?item=." The Semantics Recognition Buyer 
Agent 20 uses the user's input parameter(s) and the search form URL to compose a 

30 new HTTP request for each of the identified online vendors. For instance, if the user 
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wants to buy a "hard disk," the new request composed by the Semantics Recognition 
Buyer Agent 20 will be as follows: 

"http://www.onlineshop.com/search. asp?item=harddisk," 

5 

and the Semantics Recognition Buyer Agent 20 will send this HTTP request to the 
online vendor as if the user submitted the request himself. If there are N identified 
vendors, the Semantics Recognition Buyer Agent 20 will initiate N threads to fill-in the 
search form for each of the N identified vendors. The Semantics Recognition Buyer 

10 Agent 20 preferably proceeds in parallel to each online vendor's searchable index, fills it 
in and submits a search request. 

In step 350, the Semantics Recognition Buyer Agent 20 will wait for the response 
from the online vendor within a specified timeout or a user-defined timeout. If a timeout 
occurs, the Semantics Recognition Buyer Agent 20 proceeds to step 370; otherwise it 

15 will go to steps 358 and 360 to further process the received search result data. 

Within the timeout period, the Semantics Recognition Buyer Agent 20 collects 
the search request's responses from different online vendors. In step 358, the 
Semantics Recognition Buyer Agent 20 receives the search result responses from the 
online vendors and stores them in cache or memory within the server 22. In step 360, 

20 the data of interest is extracted from the received responses. The Semantics 

Recognition Buyer Agent 20 extracts the desired data using the information in the 
vendor description list stored in the vendor description 28 or offline database 24. To 
exemplify, the vendor descriptions include fields that identify the codes for left and right 
wrappers. Firstly, the Semantics Recognition Buyer Agent (SRBA) 20 will use the left 

25 wrapper information to locate the start of the valid data in the response page. 

Afterwards, the data at the exact location (as defined by the information in the vendor 
description list) of the target data will be extracted and stored in the memory. (Recall 
that the information in the vendor descriptions are what have been learned by the 
Semantics Recognition Learner Agent 18 during the learning process of Figures 3 and 

30 6.) The extraction of the target data will be repeated until the end of the page. 
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In the extraction process, for example, the product description and the product 
price will be extracted. It is to be understood that the information contained in the 
vendor descriptions defined by the Semantics Recognition Learner Agent 18 are 
domain independent and multi-language dependent. For example, assuming that the 
5 online buyer or user's platform uses a Windows 98 Operating System and is running a 
language version "B" (or preferably his or her platform is running Windows 2000 
Professional in the English version and/or his or her platform has a Personal Web 
Server version "B" installed), the Microsoft Internet Explorer will prompt him or her to 
download "B" language display software after he or she logs on to the portal of the 

10 present invention. After the online buyer or user "A" enters a product model in the 

native characters of language "B" as a keyword in the text box provided at the portal of 
the present invention, the Semantics Recognition Buyer Agent 20 in Figure 2 will 
perform the data extraction using pre-described example data (retrieved earlier in the 
vendor descriptions after real-time wrapper induction learning) and which contain native 

15 character string for the product model in language "B." These vendor descriptions are 
stored in the pre-defined data structure in the vendor description list in the offline 
database 24 (preferably a Microsoft Access database). The data extraction involves 
contemporaneously searching for "hits" — which contain price, description, and the 
related information of the product from the previous search results — that reside in the 

20 memory or cache stored in the server 22 using the exact native character string for the 
product model in language "B" entered by the user as exhibited in Figure 15C, step 312. 
Because the character string in language "B" is in the specific native language, any 
"hits" that are found will be for that identified vendor site using the native language "B" 
and having the character string in language "B." 

25 Recall that in step 7 of Figure 14, during the learning process, the vendor 

descriptions are stored in the vendor description list in the database 24 (preferably a 
Microsoft Access database) or database server 22 (preferably an Microsoft SQL- 
complaint database server) after the Semantics Recognition Learner Agent 18 in Figure 
2 has learned the wrapper from the online vendors. Because it is inefficient for the 

30 Semantics Recognition Buyer Agent 20 to retrieve the data of vendor descriptions each 
time upon request for the online human buyer / user, the vendor descriptions preferably 
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will only be retrieved from the offline database 24 or server 22 if it is the first time the 
Semantics Recognition Buyer Agent 20 requests a search-match-extraction of a desired 
set of them. Then the vendor descriptions will be stored in the memory or cache for 
more instantaneous retrieval and use in other later requests from the Semantics 
5 Recognition Buyer Agent 20 for the same or new online user. 

The vendor descriptions in memory or cache are preferably automatically 
updated once a day. 

In other words, the Semantics Recognition Buyer Agent (SRBA) 20 can use the 
data in the vendor descriptions to locate target data in different domains and different 

10 languages. This is because, for a particular vendor, although the language may 

change, the underlying coding corresponding to the target information will not. As the 
three "formatting regularities" predominate most vendor sites, such as B-to-C, C-to-B, 
C-to-C online stores, etc., different domains on a vendor site will consistently use the 
same formatting and underlying coding to present the target information, such as item 

15 description and price. 

Therefore, for each returned search response, the Semantics Recognition Buyer 
Agent 20 will perform the data extraction using the vendor descriptions. If the time is 
out, the Semantics Recognition Buyer Agent 20 will go to step 370, in Figure 15C. In 
step 370, the Semantics Recognition Buyer Agent 20 sorts the extracted data from 

20 different online vendors based on the user defined sorting criteria. If the user does not 
define the sorting criteria, the default will be the price of the product. Alternatively, the 
sorting criteria can be to identify the best price found, and to present to the user / buyer 
only the information from the vendor with the best price. (Incidentally, other sorting 
criteria can be used.) 

25 After the sorting is done, the Semantics Recognition Buyer Agent 20 will go to 

step 380. In step 380, the Semantics Recognition Buyer Agent 20 composes HTML 
pages based on the filtered and sorted data from step 370. In step 390, Semantics 
Recognition Buyer Agent 20 responds to the user request by presenting the composed 
HTML page as a "result" page to the user using the ActiveX component established 

30 previously. 
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If time is not out in step 350, the Semantics Recognition Buyer Agent 20 will go 
to step 358. In step 358, the Semantics Recognition Buyer Agent 20 stores data of the 
search results pages in the memory or cache for use in instantaneously responding to 
further new requests of the same user / buyer or to the request of a new user / buyer. 
5 Following step 358, the Semantics Recognition Buyer Agent 20 will go to step 360 in 
which it extracts target information from the search results pages, sorts the results in 
step 370 and the extracted data retrieved from different online vendors based on the 
user-defined sorting criteria, then composes HTML pages in step 380 based on the 
filtered and sorted data from step 370, and finally in step 390 responds to the user / 

10 buyer using the ActiveX component established previously. 

The default language of the Semantics Recognition Buyer Agent 20 is English. 
By default, the Semantics Recognition Buyer Agent 20 will go to all vendors when it 
receives the request of a user. When the responses return, the Semantics Recognition 
Buyer Agent 20 will use the vendor descriptions which have already been learned by 

15 the Semantics Recognition Learner Agent 18 to filter out invalid results. 

In another embodiment of the present invention, the vendors can be classified to 
the user's locale so that the user 12 can choose an "advanced search" to search for that 
classified group of vendors. 

The employed methodologies of the present invention are multilingual in nature. 

20 When the Semantics Recognition Learner Agent 18 learns a vendor site, such learning 
can be performed in the native language of that site. The results which are retrieved 
and used to populate the vendor descriptions for that site will be in the native language 
of that site. Thus, when an online user / buyer 12 submits a request in a particular 
native language in step 310 of Figure 15C, the Semantics Recognition Buyer Agent 20, 

25 in step 312, will look in memory or cache for "hits" using the exact character string 
entered by the user. Because the character string will be in a particular native 
language, any "hits" which are found will be for that identified vendor site using the 
same native language and having the same character string. In view of this 
methodology, it is to be understood that, in accordance with the present invention, no 

30 "translation" step is needed to convert a search request submitted in one language into 
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a "standard" language. By using the native language of the search request, the errors 
and ambiguities introduced by a translation step are avoided. 

The computer program's modules built with the database server's development 
tool (preferably a Microsoft SQL-compliant database) used in the preferred embodiment 
5 of the system of the present invention are standard and the present invention can be 
used with any relational database, such as SQL database servers from Oracle 
Corporation of Redwood Shores, California, Sybase Corporation of Emeryville, 
California, and others, that support ODBC. As mentioned above, multithreading for 
concurrent searching is important to the preferred embodiment of the present invention. 

10 In that regard, use of a Windows NT 4.0 platform (a product of Microsoft Corporation) 
can provide such a multithreading capability. 

Referring now to Figures 16 through 23, the compilation or preparation of training 
data in the "vendor list" 27 and the data of vendor descriptions in the "vendor description 
list" 28 will be elaborated in greater detail. Figure 16 is an actual screen of the 

15 Interactive-Agent-Character Learner Interface (IACLI) that can be used to obtain training 
information for use in the present invention. Using the screen corresponding to the 
"Add Vendor" tab as shown in Figure 18, data entry points are provided for entry of 
information obtained by the system administrator after the administrator's review of the 
vendor Website, "1cache.com." Thus, in Figure 17, an example is provided in which 

20 such information has been entered for the vendor "1cache.com." This information 
includes as shown below in the right column: 



Vendor's Name 


1cache.com 


Vendor's URL 


http://www.cache.com 


Vendor's Search Form 
URL 


http://st4.yahoo.com/cgi- 
bin/nsearch?catalog=1cache&query= 


Learning Domain 


Dvd 


Training Examples 


i) . DVD Virtual Notebook Theater with l-Glasses 

ii) . JVC XV523GD Dolby Digital DVD Player 

iii) . Pioneer DVL -91 9- Combination LC/DVD/CD Player 
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The above information is then saved to the vendor list 27 as training data in the 
offline database 24. It is to be noted that the training examples that have been entered 
are a list of specific products which will be searched for during the training process in 
real-time on the designated identified vendor site from which training pages will be 
5 obtained. The "vendor descriptions" will then be learned" from these returned training 
pages. 

The information can then be displayed on the screen as shown in Figure 18 
corresponding to the "Vendor Information" tab. The "Vendor Information" screen 
interface (see Figure 19) provides a "Search" function for the Vendor Name. By 

10 entering a vendor name and pressing the "Search" button, the Vendor Information for 
the vendor entered is retrieved from the offline database 24 and displayed. On this 
"Vendor Information" screen, it is to be noted that the "Wrapper" fields— "Head," "Tail," 
"Left Delimiter of Item," "Right Delimiter of Item," "Left Delimiter of Price," and "Right 
Delimiter of Price" — are empty. These wrapper fields are to be "learned." 

15 Figure 20 provides a screenshot of the Learner Interface for displaying the 

Training Examples previously entered for a particular vendor. The screen is displayed 
in response to opening a file called "Training Data." As to the "Vendor Information" 
screen of the Learner Interface, there is a search function screen provided for the 
"Training Data." To use the Training Data search function, the system administrator 

20 enters the vendor name and presses the "Go" button. This invokes the list of "Training 
Data" previously entered for the specified vendor to display as shown. It is to be noted 
that the "Training Data" interface provides other functionality, such as "Add" (to add 
additional examples), "Delete" (to delete a Training Example), "Edit" (to edit a Training 
Example), "Save" (to save the list of examples to its current state), "Cancel" (to cancel 

25 entered changes). 

Referring now to Figure 21 , a screenshot of the Learner Interface is displayed in 
response to opening a file called "Vendor Description." This interface begins the 
process of "learning" a Vendor Description, and provides for the system administrator 
the option to learn descriptions for "All" vendors for which training data has been 

30 entered, or "One" vendor of which the name has been entered by the administrator in 
the provided box. 
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In Figure 22, the "Learn One" option is shown selected, and the Vendor's name 
entered is "1cache.com." With the system being connected to the World Wide Web, 
the "Learn Now" button is to be pressed to launch the Semantics Recognition Learner 
Agent (SRLA) 18 to "learn" vendor information about the specified Vendor— 
5 1cache.com — in real-time on its Website using the training examples specified in the 
Training Examples for that vendor. 

After the learning / training process is completed, the results of the trained or 
learned examples which have been returned from its site are displayed on the Learner 
Interface's screen as illustrated in Figure 23. Again, to display this information, the 

10 system administrator can use the search function on the Vendor Information screen in 
Figure 19, to enter the name of the vendor, in this case, "1cache.com," and press the 
search button. Instantaneously, Figure 23 displays the learned results for the vendor, 
"1cache.com." It is to be noted that the "Wrapper" fields have now been completed. 
Also, the "Head" of the page is shown as occurring at value "5230." This value "5230" 

15 identifies lines, character positions, or other positional information. The "Tail" indicates 
that Items' locations as being identified by the delimiter string as follows: 

"D></TD><TD></TD></TR></" 

20 For the Item description information, the Left Delimiter is identified as the string 

below: 

"G SRC=/Lmg/trans+1X1.gifBORDER-0WID 

25 The Right Delimiter of the Item description is identified as the string: "</b>." 

The Left Delimiter of the Price is identified as the string below: 

"</b></A></TD> <TD ALIGN=right><FON 

30 Finally, the Right Delimiter of the Price is identified as the string: "</T." 
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Although the character strings in Figure 23 for the Left Delimiter of Item and the 
Left Delimiter of Price appear truncated due to the still-display state of the Learner 
Interface, it is to be understood that all of the characters in the left delimiter strings 
identified by the Semantics Recognition Learner Agent 18 will be stored in the vendor 
5 descriptions 28, preferably in a Microsoft Access database, and will be later used by the 
Semantics Recognition Buyer Agent 20. 

The methodology underlying the Semantics Recognition Learner Agent 18 will 
now be described in more detail at a "proof-of concept" level. 

Basic Concepts 

10 The wrapper induction problem is framed in the form of a simple model of 

information extraction as shown in Figure 24. 

As exhibited in Figure 24, a PAGE P is the Web page containing the desired 

information. P is taken to be a string over some alphabet. Typically, the alphabet is the 

ASCII character set, and the PAGES are HTML documents. To exemplify, Figure 7 as 
15 elaborated earlier, is a very simple page obtained from a vendor site. In "labeling 

terminology," this page will hereafter be referred to as Ppc (Page of product catalogue). 

Note that the methodology of the present invention is motivated or invoked by, but does 

not rely on, the use of HTML. For instance, the pages might be natural language text or 

might comply with the XML standard. 
20 A standard relational data model is adopted. Associated with each product 

record are two distinct attributes: item and price. Where "item" represents the product 

name or model number," and price represents the price of a product. 

A "tuple" is a vector <Ai, Ap> of two strings. String Ai is the value of the "item" 

attribute, and string Ap is the value of "price" attribute, whereas attributes represent 
25 columns in the relational model, "tuples" represent rows. Thus, as illustrated in Figure 

8, the example of product catalogue page of Figure 7 contains four "tuples," the first of 

which is <'HM381MD\ '399.95'>. 

The content of a page is a set of "tuples" that it contains. For example, the literal 

string notation is adequate, but since pages have unbounded length, a clearer and more 
30 concise representation of a page's content is used instead. Rather than listing the 
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10 



15 



attributes explicitly, a Page's "label" is used to represent the content of a page in term of 
a set of indices in the Page. 

For example, the "label," Lpc, for the simple product catalogue page (Ppc) is 
illustrated in the right-hand column of Figure 8. 

The "label" Lpc indicates that the simple product catalogue page contains four 
"tuples," where each "tuple" consists of item and price values. A pair of integers 
represents each of the values. Consider the first pair, <174, 180>. These integers 
indicate that attribute of the first tuple is the sub-string between position 174 and 180, 
i.e. the string 'HM381 MD\ Inspection of the character strings of the right-hand side of 
Figure 7 reveals that these integers correspond to character positions, starting from the 
"<" in "<HTML>" in the first line. Similarly, the last pair of integers in the fourth "tuple," 
<356, 361 >, indicates that the last attribute's price occurs between 356 and 361 , i.e. the 
string '399.95'. 

More generally, the content of page P can be represented by label L. 



L = 



(b k j>ekj)>{ b k.p> e k.p) 



For a page with only single "tuple," the following label results: 

i=K(ft 1 ,, ei ,),(^, ei ,„))} 

20 Label L encodes the content of page P. The page contains I LI > 0 "tuples," each 

of which has two attributes, item and price. The integers 1 < m < ILI index "tuples" 
within the page. Each pair <b mii , e m>i > encodes an item value, and each pair <b m , p , e m , p > 
encodes a price value. The value bmj is the index in P of the beginning of an item in the 
mth "tuple," the value e m ,j is the end index of an item value in the mth "tuple." Similarly, 

25 the value b m , p is the index in P of the beginning of a price in the mth "tuple," the value 
e mtP is the end index of a price value in mth "tuple." Thus, the item attribute of mth tuple 
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occurs between <b m ,j, e m j>, the price attribute of mth "tuple" occurs between <b m>p , 
e m , P > - Thus, the pair <b 2 j, e 2| j> = <229, 234> in the example of Figure 8 encodes the 
second (item) attribute of the second "tuple" in the simple product catalog of the page in 
Figure 7. 

5 As shown above, a wrapper W is a function from a page to a label; the notation 

W(P) = L indicates that the result of invoking wrapper W on a page P is label L. At this 
level of abstraction, a wrapper is simply an arbitrary procedure. 

A wrapper class is a set of wrappers. As will be seen later herein, the wrapper 
employed by the present invention is called an HLRT wrapper class. 

10 In view of the foregoing explanation of terminology and conventions used to 

describe the methodology of the present invention, further explanation will now be 
provided as to how the learner learns a wrapper for a vendor's product catalog pages. 

Intuitively, the input to the learning system of the present invention is a sample of 
product catalogue pages and their associated "labels." At this point, it is assumed that 

15 the "labels" have already been identified and are given. A further elaboraion of the 
method used to generate labels for a sample page will be provided herein later. The 
output is a wrapper W e W. Ideally, W outputs the appropriate label for all of sample 
pages. In general, such a guarantee cannot be made, so (in the spirit of inductive 
learning) it is required that W generate the correct labels for a given set of training 

20 examples. 

Solutionwise, the wrapper induction problem (with respect to a particular class 
W) is as follows: 

Input: a set £ = {..., <Pn, Ln>, ...} of training examples, where each Pn is a page, 
and each Ln is a label; 
25 Output: a wrapper W e W, such that W(Pn) = Ln for every <Pn, Ln > e e. 



The HLRT Wrapper Class 

As explained herein earlier, the pcwrapHLRT procedure illustrates a 
"programming acronym" — using head delimiter, left-hand delimiter, right-hand delimiter 
30 and tail delimiter to extract relevant product information and its price from a vendor 
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product catalogue. The Head-Left-Right-Tail (HLRT) wrapper class is one way to 
formalize this acronym. The procedure "execHLRT" set forth in Figure 25 is a 
generalization of pcwrapHLRT that allows the delimiters to be arbitrary strings, instead 
of the specific values "<B>," "</B>," etc., used in the previous implementation of 
5 pcwrapHLRT. 

Note that although the delimiters in this example are entire HTML tags, the 
methodology of the present invention is not limited to operating with HTML tags. 
Furthermore, the text might not be HTML at all. Thus, the dollar sign symbol, "$," might 
be valid left delimiter for price such as "$399.95." 

10 The execHLRT routine specifies how HLRT wrappers behave. Earlier it was 

stated that the W(P) is the label that results from invoking wrapper W on page P. The 
routine execHLRT is a procedure for determining W(P) and from W and P, for the case 
when W is an HLRT wrapper. 

The values of I, and r,-, indicate the left-hand delimiters and right-hand delimiters 

15 for the item attribute, while l p and r p indicate the right-hand delimiters for the price 

attribute, and h and t indicate the head and the tail of the page, respectively. (Note that 
h is a line number instead of a string. For example, if h = 100, then the first 100 lines of 
the page is the head, the Semantics Recognition Buyer Agent 20 may skip these lines 
immediately when it search for a product.) For example, if execHLRT is invoked with 

20 the parameters h = 7, li = "<B>," ri = "</B> M lp = "<l>," rp = "</l>" and t = "</TABLE>," 
then execHLRT behaves like pcwrapHLRT. 

More generally, any HLRT wrapper for a vendor site is equivalent to a vector of 
(h, I,, r,, l p , r p , t), and any such vector can be interpreted as an HLRT wrapper. Given 
this equivalence, the notation (h, I/, r,-, l p , r p , t), is used as shorthand for the HLRT 

25 wrapper obtained by partially evaluating execHLRT with the given delimiters. 

Since an HLRT wrapper is simply a vector (h, I/, r,-, l p , r p , t), the HLRT wrapper 
induction example of Figures 7 and 8 thus is one of identifying four (4) delimiter strings 
(h, l„ r„ l p , r p , t), on the basis of a set £={... (P, (P n , L n ),.. .} of the example pages and 
their labels. More precisely, the following constraint satisfaction problem (CSP) is to be 

30 solved: 

variables: Head delimiter of the page P: h 
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Tail delimiter of the page P: t 
Left delimiter of the item attribute: I, 
Right delimiter of the item attribute: r,- 
Left delimiter of the price attribute: l p 
5 Right delimiter of the price attribute: r p 

domains: each delimiter is an arbitrary string, except the head delimiter; 
constraints: W(Pn) = Ln for every <Pn, Ln> e e, where HLRT wrapper 

W = (h, I/, r y , l p , r p , t), 
The learnHLRT methodology will now be described which addresses the above 
10 constraint satisfaction problem. 

Delimiter candidates 

To begin, it is to be noted that the domains of the delimiter variables are tightly 
constrained by the examples e. At the very least, the delimiters will be sub strings of the 
example pages. Of course, one can do much better. On the basis of just the single 
15 example (Ppc, Lpc), it can be seen that r p (the right-hand delimiter for the price attribute) 
must be a prefix of "</l></TD></TR>," where "U" indicates a new line character. By 
"prefix" it is meant combinations of the characters in the string, starting from the right- 
most character of the string; for example, ">," "D>," "TR>," etc. 

Note that if r p is not a prefix of this string, then every wrapper with this delimiter 
20 will, at the very least, fail to extract "399.95" as the code attribute for Ppc's fourth "tuple." 
Thus the candidates for r p are all prefixes of "</l></TD></TR>." These candidates are 
illustrated in Figure 10A. 

In detail, the candidates for the delimiters for the simple product catalogue page 
are generated as follows: 

25 Candidates for the \\ and l D 

Consider l p , the left-hand delimiter for the price attribute. Recall the fragments 
"HM381MD</B></TD><TD><I>," "MD2070</B></TD><TD><I>," etc., that precede the 
price in Figure 7. Given these fragments, it can be seen that l p , must be a suffix of 
"</B></TD><TD><l>." Thus the candidates for l p are the 16 non-empty suffixes of this 

Gray Cary\SF\3098970.2 -40- 
2102680-991000 



string. These candidates can be seen in Figure 10A. By "suffixes" it is meant 
combinations of the characters in the string, starting from the left-most character of the 
string; for example, "<," "</," "</B," "</B>," etc. 

Delimiter lj is more complicated because the string prior to the first attribute 
5 occurs between the first attribute and the last attribute of the previous "tuple," as well as 
between the head of the page and the first "tuple." In the example, the strings under 
consideration are "<TR><TD><B>" and "</l></TD></TR>U<TR><TD><B>." Clearly, lj is 
a suffix of this string. Thus, the candidates for h can be generated by enumerating the 
suffixes of one such fragment. 

10 To generalize this elaboration, it is concluded that the candidates for delimiter lj 

and l p , given the example set and written candsi(i, p, e ), are generated by enumerating 
the suffixes of the shortest string occurring to the left of each instance of item attribute 
or price attribute in each example. (As mentioned in the previous paragraph, the case 
item attribute is somewhat special. The suffixes of the shortest string either between 

15 adjacent tuples or before the first tuple must be enumerated.) For example, if e = {(Ppc, 
Lpc)}, then: 

Cands,(i, e ) = {</l></TD></TR>U<TR><TD><B>, 
....) 

Candsi(p, e ) = {</B></TD><TD><l>, 
20 . . . . } 

Candidates for the n and r Q 

The candidates for the right-hand delimiters are generated similarly. But there 
are two distinctions. Firstly, the strings under consideration occur to the right of the 
appropriate attribute (rather than to the left). Secondly, n and r p must be a prefix (not a 
25 suffix) of these strings. For example, in the simple product catalogue example, the 

delimiter n must be a prefix of the string "</B></TD><TD><l>," while r p must be a prefix 
of both "</l></TD><TR>" and "</l></TD><TR>U<TR><TD><B>." 

In particular, the candidates for right delimiter given the example set e — written 
cands r (k, e) are generated by enumerating the prefixes of the shortest string occurring 
30 to the right of each instance of attribute k in each example. (As stated above, lj is a 
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special case. Similarly, r p is a special case. The prefixes of the shortest string 
occurring either between adjacent "tuples" or after the last "tuple" are enumerated. For 
example: 

Cands r (i, e) = {</B></TD><TR><l>, 
5 ....} 

Cands r (p, e) = {</I></TD><TR>U<TR><TD><B>, 
....} 

Candidates for the head and tail 

A similar analysis applies to delimiters for the head and tail. The "head" is the 
prefix of the page before the first item attribute occurs. Note that here, the "head" is 
represented as a string. When a wrapper is in actual implementation, in order to 
increase the performance of the invention, it is preferable to represent the "head" as an 
integer so that the human shopper or buyer, in using the wrapper to look for product 
information, can skip a page's head quickly without looking into the content. To convert 
a head string to an integer, simply find out the number of lines that are spanned by the 
head string. 

Identifying the delimiter for the "tail" is quite similar to the right delimiter lj and L p . 
The tail candidates are the suffixes of the string after the last price attribute of the page. 
Cands(head, e) = {<HTML>U<TITLE> . . . PRICE($US)</TH></TR>, 
....} 

Cands(tail, e) = {</l></TD></TR>ll</TABLE> . . . <HTML>, 
....} 

Delimiter Independence 

Given these candidates for each delimiter, a module of the simple method in 
25 pseudo-code for learning these two delimiters is provided in Figure 26. 

Because the module runs in time proportional to the product of the number of 
candidates for each delimiter, and because each delimiter can have many candidates, 
execution time can be slow. 
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A more efficient processing can be accomplished by observing that the delimiters 
n, l p , r p are mutually independent. Furthermore, whether a candidate is valid for a 
particular delimiter in no way depends on any other delimiters. For example, it can be 
evaluated whether "</B>" is satisfactory for n without reasoning about any of the other 
5 delimiters. 

To see that this independence properly holds, recall the execHRLT procedure. 
At each point in its execution, execHRLT is searching for its input page P for exactly 
one of the delimiters n, l p , r p . If any of these searches fails to identify the correct location 
in P, then the label output by execHRLT will be incorrect. But whether these searches 
10 return the right answer depends only on the delimiter under consideration and the 
example pages — not on the other delimiters. 

Put another way, once a particular candidate (n, l p , r p ) is chosen for some 
delimiter, there is no way the candidate can be made invalid, no matter what candidates 
are selected for the other delimiters. The contrapositive of this assertion also makes 
15 intuitive sense: if a candidate is invalid, there is no way to repair it, no matter how 
carefully candidates are selected for other delimiters. Note that this independence 
property is guaranteed; it is not merely heuristics that facilitates learning. 

The significance of this observation is that the three delimiters, n, l p , r p , can be 
learned in isolation. In pseudo-code, they can be learned as follows: 
20 1 . Generate the candidate sets 

2. For each delimiter, select a valid candidate. 

This methodology is much faster than the procedure of Figure 26: it runs in time 
proportional to the sum (rather than product) of the number of candidates for each 
delimiter. 

25 However, it is also observed that not all the delimiters are mutually independent. 

In contrast, as to delimiters h, t, and l if whether a particular character string is valid for 
one of these three delimiters depends on the choice for the other two. For example, is 
"<B>" valid for lj? The answer depends on the choice for the choice for h and t. If h = 
"<HTML>," then "<B>" is not a valid delimiter for lj because execHLRT will not skip the 

30 irrelevant bold text "<B>A Simple Product Catalogues</B>." On the other hand, if h = 
"</TH></TR>," then lj ="<B>" causes no problem. Similarly, lj and t interact: lj = "<B>" is 

Gray Cary\SF\3 098970.2 -43- 
2102680-991000 



unacceptable if t = "</HTML>," but acceptable if t = "</TABLE>." As a result, 
candidates for the three delimiters h, t and lj must be considering jointly. Thus, all 
combinations of candidates for h, t and lj are enumerated, and the valid ones are 
selected. 

5 Candidates validity 

The second step of this improved methodology involves precisely characterizing 
the conditions under which a delimiter candidate is valid. 

Consider first the delimiter n and r p . After the method has identified the beginning 
of some instance of the attribute, the method attempts to locate the end of that instance 
10 of the attribute. Thus a candidate, "u" for delimiter n or r p must satisfy two constraints: 
Constraint C1 : "u" must not be a sub string of any instance of an attribute in any 

of the example pages. 
Constraint C2: "u" must be a prefix of the text that occurs immediately following 
each instance of the attribute in every example page. 
15 If these constraints are violated by a candidate "u" for delimiter n or r p , then every 

wrapper will fail for at least one of the examples e. If constraint C1 is violated, then 
attribute k will be too short; if C2 is violated, it will be too long. 

In summary, of interest are the conditions that must hold if some candidate "u" is 
to be valid as a value for delimiter n or r p , with respect to a given set of examples e. 
20 These conditions will be referred to as valid (u ,r, e). It is seen that valid r (u ,r, e) holds if 
and only if candidate "u" satisfies constraints C1 and C2 for delimiter n and r p with 
respect to example set e. Returning to the example, if the validr test is applied to the 
candidates generated by cands r , it is found that: 
For the right delimiter of the item attribute: 
25 validr(</B></TD><TD><l>, i, e) = TRUE 



For the right delimiter of the price attribute: 
validr(</|x/TD><TR>U<TR><TD><B>, p, e) = FALSE 
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Constraints on l n 

The execHLRT procedure searches for delimiter l p . A candidate "u" for the 
delimiter l p must satisfy two constraints: 

Constraint C3: "u" must be a proper suffix of the text that occurs immediately 
before each instance of the attribute k in every example page. 
If this constraint is violated, then every wrapper will disagree with the examples e. 
At least, one of the starting indices b m , p computed by execHLRT will be incorrect — 
either less or greater than the correct value, or undefined, depending upon how "u" 
violates the constraint. 

In summary, of interest are the conditions that must hold if some candidates "u" 
are to be valid as a value for delimiter l p according to example set e. These conditions 
are referred to as validj(u, I, e). It is seen that validi(u, I, e) holds if and only if candidate 
"u" satisfies constraints C3 for delimiter l p with respect to C. Returning to the simple 
product catalogue example Ppc, it is seen that: 
valid,(</B></TD><TD><l>, p, s) = TRUE 

To determine whether a particular combination of candidates Uh, Ut, and Ulj for 
h, t, and lj are satisfactory, the constraints below are applied: 
20 Constraint C4: Uh must be a proper suffix of the portion of every page's head. 

Constraint C5: Uh must be a proper suffix of the portion of every page's head 

after the first occurrence of Uh. 
Constraint C6: Ut must not occur between the first occurrence of h in any page 
and the subsequent occurrence of lj. 
25 Constraint C7: Ut must be a sub string of every page's tail. 

Constraint C8: Ulj must not occur before t in every page's tail. 
Constraint C9: Ulj must be a proper suffix of the text between "tuples" in every 
page. 

Constraint 10: Ut must not occur before Ulj in the text between "tuples" in any 
30 page. 
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HLRT Induction 

With this background in place, procedure learnHLRT will now be described. A 
table of the detailed procedure as well as the related subroutines are provided in 
Figures 27A and 27B. 

5 Obtaining the Training Data 

In the earlier description of the present invention it has been assumed that the 
training data was already in place for use by the Semantics Recognition Learner Agent 
18. That is, a set e = {. . . , <Pn>, Ln>, . . .} of training examples was already in 
existence, where each Pn is a page and each Ln is a label. To further understand how 
10 the Learner 18 works with the training examples, reference is made to Figures 7 and 13. 
As stated earlier, at the shopping/buying phase, the Semantics-Recognition 
Buyer Agent 20 can perform five different functions which are as follows: 



15 



(1) To compose Labels (LabelOracle) using a modular heuristic search 
methodology as described in Figure 15C. These are referred to as recognizers: 
One of which is an item recognizer and the other an intelligent price recognizer. 



20 



(2) Because it is inefficient for the Semantics Recognition Buyer Agent 20 
to retrieve the vendor descriptions data each time it receives a request from the 
online human buyer or user, such descriptions will only be retrieved from the 
database (preferably a Microsoft Access database) or SQL-compliant database 
server 22 if it is the first time the Semantics Recognition Buyer Agent 20 requests 
the search-match-extraction of a desired set of them. Then the vendor 
descriptions will be stored in the memory or cache for more instantaneous 
retrieval use in other later Semantics Recognition Buyer Agent 20 requests. 



25 



(3) The vendor descriptions in memory or cache preferably will be 
automatically updated once a day. 



30 



(4) The system of the present invention creates multi-threads and zaps 
simultaneously several Semantics Recognition Buyer Agents to contact various 
designated online vendor sites through the World Wide Web. The use of this 
multi-threading methodology is preferably built on top of DOOM technology 
offered by Microsoft Corporation. Each Semantics Recognition Buyer Agent 20 
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intelligently fills-in the vendor's search form with the product information provided 
by the human buyer or user and presses "enter" virtually. 

(5) On the other hand, the Semantics Recognition Buyer Agent 20 of the 
present invention addresses heavy network traffic on the World Wide Web, now 
5 dominating the whole process of a shopper/buyer's online purchase, by speeding 

up vendor response times and allocating returned search result pages to 
separate memory locations as enabled by multi-threading. 

Training pages Pn 

Obtaining a training page involves making an example query to a vendor 
10 Website. For example, Figure 12 illustrates the appearance of an example page from a 
query to a Website, such as to http://www.800.com. 

The algorithm in which the recognizer, referred to as Label (LabelOracle), is 
composed from modular heuristics search methodology, will now be described in 
greater detail. A recognizer finds instances of a particular attribute on a page. For 
15 example, given the example page of Figure 12, an item recognizer would identify all 
"items" contained in the page, e.g. the products "HM381MD," "MD2070," and "MD203." 
A recognizer should be intelligent enough to prune the noise. 

For example, again, given the example of Figure 12, an intelligent price 
recognizer is able to distinguish between "Price 1 and Price 2, which might be, for 
20 example, "List Price" and "Your Price," respectively. The recognized instances are then 
corroborated to label the entire page. For example, given a recognizer for "items" and 
another for "price," the corroboration produces a LabelOracle that labels pages 
containing pairs of these attributes. 

Recognizing the "items" is a simple pattern-matching problem if the item 
25 recognizer knows all items in advance. Nevertheless, this is infeasible because this 
requires a big list of item names/model numbers. Moreover, it is costly to maintain such 
a large database of items. Thus, it is not practical to guarantee that such a list of item 
names/model numbers is complete and up-to-date. 

Fortunately, vendors attempt to create a sense of identify by using a uniform look 
30 for all products. For example, a vendor presents mini-disc (MD) product information in 
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the same format as for a DVD product. By taking advantage of this regularity, it is 
assumed that every product is described in the same format. 

The present invention learns a wrapper only from a specific domain of examples 
and attempts to fit this domain to all other domains in foreign languages organized in a 
5 consistent format globally on the Internet. In the preferred embodiment, the training 
examples solely originate from one domain, such as the MD domains of the vendor 
Websites. This results in the item recognizer that merely needs to recognize a specific 
domain of product, such as MD. In this manner, it is then feasible to maintain a 
thoroughly updated nomenclature of a specific domain of item names. 
10 The present invention identifies a "price" by invoking a modular heuristic search. 

For instance, a price always follows a dollar sign ($); and a price is often a floating-point 
number, etc. If more than one price is found for an item, the keywords, such as "your 
price," "our price," "list price," "original price," etc are then extracted accordingly. 

Detailed Steps Of The Shopping Phase 

15 As described briefly earlier, the mechanism of how the Semantics Recognition 

Buyer Agent 20 works is illustrated in Figures 14 and 15A-15C. The flow of control 
consists of eight (8) steps that are labeled in the graphical diagram. 
Step(1) 

When a user identifies the need for a particular product, or services, instead of 
20 browsing into different multilingual vendors sites on the World Wide Web in a manual 
search for product information and price, ONE-BY-ONE, the present invention provides 
a portal through which the request for product information is entered once through an 
interactive-agent-character graphical user interface (IACGUI), commonly known as 
interactive-agent-character shopper/Buyer interface to achieve the same purpose, but 
25 with better, faster and more reliable results. 

The resulting product description is stored in the member variable — 
m_ProdDesc — of the SRBA 20. The search also enables the user to customize how the 
agent works through the "Advanced Search" function, which provides selectable 
parameters such as vendors of choice, the time out (limit), price range, any 
30 manufacturers, keywords, and so forth. 
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Step (2) 

Assuming, for example, that the online buyer or user's platform uses a Windows 
98 Operating System and is running a language version "B" (or preferably his or her 
platform is running Windows 2000 Professional in the English version and/or his or her 
5 platform has a Personal Web Server version "B" installed), the Microsoft Internet 
Explorer will prompt him or her to download language "B" display software after he or 
she logs on to the portal of the present invention. After the online buyer or user "A" 
enters a product model in the native characters of language "B" as a keyword in the text 
box provided at the portal of the present invention, the Semantics Recognition Buyer 

10 Agent 20 in Figure 2 will perform the data extraction using pre-described example data 
(retrieved earlier in the vendor descriptions after real-time wrapper induction learning) 
and which contain native character string in language "B." These vendor descriptions 
are stored in the pre-defined data structure in the vendor description list in the database 
24 (preferably a Microsoft Access database). The data extraction involves 

15 contemporaneously searching for "hits"— which contain price, description, and the 
related information of the product from the previous search results— that reside in the 
memory or cache stored in the server 22 using the exact native character string in 
language "B" entered by the user as exhibited in Figure 15C, step 312. Because the 
character string in language "B" is in the specific native language, any "hits" that are 

20 found will be for that identified vendor site using the native language "B" and having the 
character string in language "B." 

Recall that in step 7 of Figure14, during the learning process, the vendor 
descriptions are stored in the vendor description list 28 in the offline database 24 
(preferably a Microsoft Access database) or database server 22 (preferably an Microsoft 

25 SQL-complaint database server) after the Semantics Recognition Learner Agent 18 in 
Figure 2 has learned the wrapper from the online vendors. Because it is inefficient for 
the Semantics Recognition Buyer Agent 20 to retrieve the data of vendor descriptions 
each time upon request of the online human buyer or user, the vendor descriptions will 
only be retrieved from the database 24 or server 22 if it is the first time the Semantics 

30 Recognition Buyer Agent 20 requests a search-match-extraction of a desired set of 
them. Then the vendor descriptions will be stored in the memory or cache for more 
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instantaneous retrieval and use in other later requests from the Semantics Recognition 
Buyer Agent 20 for the same or new online user. 

The vendor descriptions in the memory or cache preferably are automatically 
updated once a day. 
5 Step (3) 

Using the retrieved vendor descriptions, the system of the present invention 
creates multi-threads and zaps simultaneously several Semantics Recognition Buyer 
Agents 20 to contact various designated online vendor sites through the World Wide 
Web. 
10 Step (4) 

The use of this multi-threading methology is preferably built on top of DCOM 
technology offered by Microsoft Corporation. Each Semantics Recognition Buyer Agent 
intelligently fills-in the vendor's search form with the product information provided by the 
human buyer or user and presses "enter" virtually. 
15 Step (5) 

Each vendor then returns a search result page having the information of the 
requested product or an error message. 

Steps (6), (7) 

The search results pages are returned to the Semantics Recognition Buyer 
20 Agents 20 through the World Wide Web. It is noteworthy that several results pages 
may arrive back at the Semantics Recognition Buyer Agents 20 at the same time. The 
Semantics Recognition Buyer Agents 20 of the present invention address heavy 
network traffic on the World Wide Web which currently dominates the whole process of 
a shopper/buyer's purchase by speeding up vendor response times and allocating 
25 returned search result pages to separate memory locations as enabled by multi- 
threading. 

Stage (8) 

The Semantics Recognition Buyer Agent 20 analyzes the returned pages 
according to the corresponding vendor descriptions. Relevant information and data are 
30 extracted from the returned pages and are displayed in a formatted output fashion as 
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shown in Figure 15B after all search result pages have arrived or the search is timed 
out. 

Referring to Figure 28, the User / Buyer communicates with the server 22 to run 
the in-process DLL file (NextGen.dll) on the server machine 22 through an Active Server 
5 Page (ASP) file (NextGen.asp) as shown. 

Preferably, developing the Semantics Recognition Buyer Agent 20 as an ActiveX 
Component produces several advantages. Firstly, overall performance can be 
improved. Writing the Semantics Recognition Buyer Agent 20 in Visual C++ permits the 
agent to be robust and makes available the powerful functionality of the ActiveX 
10 Component. There is no need to supply workaround solutions in the HTML and 

scripting code to meet the needs of the application. With the ActiveX Component, the 
agent can be run by adding a few lines of the code in the HTML file in the client side, 
while leaving aside all complex processes to be executed in the server side. 

Secondly, ActiveX Components provide reusability to other applications instead 
15 of copying similar functions in every application module. An ActiveX component can be 
created to be accessible to all Active Server Pages modules. In other words, it is not 
required that all the logic be coded in ASP modules. Thus, this eliminates the 
redundancy in the application. Albeit the Semantics Recognition Buyer Agent is created 
within a single application, it does not hinder the ability to integrate with other 
20 applications as well. Furthermore, this feature can help reduce the development time 
significantly. 

Thirdly, it is beneficial to connect an ASP Component to DLL (Dynamic Link 
Library) files as they are compiled and linked independently. No additional 
recompilation and re-linkage are needed to update the ASP Component. Hence, speed 
25 improvement or new functionality of later upgraded version can benefit the ActiveX 
Components that use the DLLs. Besides, DLLs can reduce memory and disk space 
requirements by sharing a single copy of common code and resources among multiple 
modules. 

If there are several components using the same static link libraries, several 
30 identical copies of the library are required to be stored and executed. Then there will be 
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several identical copies in memory if they run simultaneously. So, it is obvious that 
using static link libraries may result in redundancy and space wastage. 

Only one copy of the code and resources are needed if a DLL is used in lieu of 
static link libraries. This can keep the server at a minimum workload as there are many 
5 concurrent connections from the Internet. 

The Semantics Recognition Buyer Agent 20 is preferably an ActiveX Component 
that is developed as an in-process DLL. It can allow user to create an object of the 
SRBA through the World Wide Web. To communicate between the user and the server, 
ASP is used to act as the gateway between the user and the server. 
10 ASP is an open application environment in which HTML pages, scripts, and 

ActiveX Components are combined to create Web-based applications. In addition, it is 
built as an Internet Server Application Program Interface (ISAPI) that runs on top of the 
Internet Information Server (IIS) product of Microsoft Corporation, or on a peer Web 
server relative of IIS. 

15 To implement ASP, Microsoft ActiveX Scripting is used, such as Visual Basic 

(VB) script that is used in the process of managing ActiveX Components. It makes the 
language dynamic by adding the ability to invoke ActiveX Components running on the 
server as DLLs. 

Program Logic — Create an object of the Semantics-Recognition Buyer Agent 

20 An object of the Semantics Recognition Buyer Agent 20 is created when the user 

starts searching for the price of the desired product. 

In the Active Server Page, the module in pseudo-code is coded as follows: 

Start sub session 
25 Set agent = server 

Create object ("NextGen ) 

End sub 

The above module creates an object of the Semantics Recognition Buyer Agent 
30 component 20 when the page is loaded, while NextGen is the name of the ActiveX 
Component. Semantics-Recognition Buyer is the name of the Agent in the NextGen 
component. 
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Connection between the User and the Server 



A connection is established between the user and the server after an instance of 
the Semantics Recognition Buyer Agent 20 has been created, as shown in Figure 29. 

The Semantics Recognition Buyer Agent uses a connectable object to maintain a 
5 "one-to-one" (channel) through which the user communicates with the server, such as a 
user request to the Server to compare the price, while the Outgoing Interface is used by 
the Semantics Recognition Buyer Agent 20 as the connection (channel) through which 
the Server communicates with the user, such as a response in which the Server returns 
the search result requested to the user. The user can access the properties and invoke 
10 the methods of the Semantics Recognition Buyer Agent through the IConnectionPoint. 

Semantics Recognition Buyer Agent 20 employs the methodologies set forth 

below: 

1 . OnStartPage (Unknown Agent) 

This methodology is used to initiate the object of the Semantics Recognition 
15 Buyer Agent that is called automatically when the ASP is loaded. 

2. OnEndPage() 

This methodology is used to terminate the object of the Semantics Recognition 
Buyer Agent that is called automatically when the ASP is unloaded. 

3. GetSearch (BStr input, BStr *output) 

20 This methodology is used to search the required product price on the Internet 

after the user has provided the product description, such as model number. Input is the 
product description of the user whereas Output is the output of the search result page. 
The syntax to call this method is: 

OutputName = AdObjectName.GetSearchfProduct Name") 

25 In the above code, AdObjectName is the object's instance name whereas 

"Product Name" is the product name which the buyer/user agent wants to compare the 
price, and the OutputName is the variable that gets the returned value. Refer to the 
pseudo-code below as an example, 
If result = Agent 

30 Get search ("Radar detector") 
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Server Side Program Logic 

Register the component 

Before the user can initiate an object of the Semantics-Recognition Buyer Agent, 
its component must be registered in the server by the following command: 

5 

Register path\Nextgen.dll 

where path is the absolute path the Nextgen.dll is saved. 

10 Response to the user reguest 

As the object of the Semantics Recognition Buyer Agent calls the method of 
GetSearch through the IconnectionPoint, an instance of the Semantics-Recognition 
Buyer Agent in the server machine executes the Dynamic Link Library (DLL). See 
Figure 30. 

15 

Connecting Database 

Data Source Name (DSN), identify (ID) and Password are needed to be provided 
to connect to the SQL Server through ODBC. RETCODE is a variable that stores the 
returned value from the SQL server. SQL_SUCCESS indicates a successful retrieval. 
20 CString sDSN = "NextGen"; 

CString sID = "NextGen"; 
CString sPassword = "NextGen"; 
RETCODE re; 

rc = SQLConnect(hdbc,sDSN,","slD,","sPassword,""); 
25 if(rc == SQL_SUCCESS) 

{ 

. . . execute query . . . 

} 

else 
30 { 

. . . error handling . . . 
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} 

Execute an SQL query 

Before retrieving the desired data from SQL, a specified query is needed. 
//Allocating a statement handle 
SQLAIIocStmt(hdbc, &hstmt); 

//query statement; model is the model number from the user 
CString sQuery="select*from tbl_electronic where model=+"moder; 
rc=SQLExecDirect(hstmt,sQuery,""); 
if(rc == SQL_SUCCESS) 

{ 

. . .retrieving fields . . 

} 

Retrieving Fields 

After succeeding in executing the query, the vendor description will be stored into 
an array called vendor_description. There are two member variables in this array: a 
wrapper and a vendor URL. 

rc = SQLGetData(hstmt,column_number, 

dataJype,sWrapper,sizeof(sWrapper)); 

if( rc ==SQL_SUCCESS) 

vendor_description[i].wrapper = sWrapper; 

rc = SQLGetDataChstmt.column^umbendataJype^URL^izeofCsURL)); 

if(rc=SQL_SUCCESS) 

vendor _description[i].url=sURL; 

Filling-in the forms 

If there are N vendor descriptions, the buyer agent will initiate N threads to fill-in 
the form in each vendor specified in the vendor descriptions. 
To run each thread, the syntax is: 

//nNoVendor is the number of the vendor description; 
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Int nNoVendor=no_of_vendor_description; 
For(lnt nCount = 0;nCount<nNoVendor; nCount++) 

{ 

//Thread FillForm is a class that implements the form filling; 
5 Thread *ThreadFillForm; 

Thread=AfxBeginThread(RUNTIME_CLASS(ThreadFillForm), . . .) 

} 

For each thread, the time limit preferably is about 5 seconds. If the vendor does 

10 not return the result within 5 seconds, this vendor will be discarded for this time, 
otherwise, the result will be stored into the memory for the use by the next process. 

When the user inputs in a provided box a keyword of the purchase request on 
the portal of the present invention, it is determined whether there are any related vendor 
descriptions; i.e. vendor descriptions which contain the keyword. All related vendor 

15 descriptions containing wrappers and URLs are then retrieved from the offline database. 
Afterwards, the Semantics Recognition Buyer Agent 20 goes in parallel with each online 
vendor's searchable index, fills it in and submits it to the vendor site. On the vendor 
site, the Buyer Agent will call a member function httpPost to complete the task. The 
httpPost member function posts a URL and form data to a vendor according to the 

20 vendor description and returns a HTML response as a string variable. The httpPost 
member function returns a Boolean value, where true indicates a successful retrieval of 
the HTML document, and false indicates that an error has occurred. If the return value 
is true, the generated item name and price will be extracted from the HTML document. 
The flow of posting a form is shown in Figure 31 . 

25 In step 1002 a Cinternet Session object for the session is created. The Cinternet 

Session class connects to a server for an Internet session. Typically this class is used 
early in a session to establish a connection to a Web server. 

In step 1004 a CHttpConnection object is created by calling the Cinternet 
Session object's GetHttpConnection member function. The CHttpConnection class 

30 establishes an HTTP connection with a server. 
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In step 1006 a CHttpFile object is createdby calling the OpenRequest member 
function of the CHttpConnection object. The CHttpFile class let file transfer over the 
Internet to be treated as if working with a local disk file. It works with the 
CHttpConnection object to read or write Internet data. 
5 Step 1 008 calls the SendRequest member function of the CHttpFile object to 

send the POST request and form data to the remote HTTP server. 

Steps 1010, 1012 and 1014 repeatedly call the CHttpFile object's Read member 
function, which returns chunks of response data to the program. When Read returns 0, 
no data is left to retrieve. 
10 Extracting Price 

After getting the result pages, the Semantics Recognition Buyer Agent 20 will 
match each result page against the generalized failure template. If the page does not 
match the template, it is assumed to be a successful search. Then the buyer agent 20 
will use the wrapper for the corresponding vendor to strip header and trailer information 
15 from the successful pages. For example, assume that a user searches for a MD 
product with the model number MD203, that a given wrapper is 
{7,<B>,</B>,<I>,</I>,</TABLE>}, and that the result page is shown below. 

<HTML> 

<TITLE>A Simple Product Catalogs</TITLE> 
20 <BODY> 

<H2> MD Price </H2> 

<TABLE BORDER=1> 

<TR BGCOLOR=ORANGE> 

<TH>ModelNumber</TH> 
25 <TH>PRICE(US$)</TH> 

</TR> 

<TR><TD><B>HM381MD</B><TD><I>399.95</I></TD></TR> 
<TR><TD><B>MD2070</B><TD><TD><I>599.95</Ix/TD></TR> 
<TR><TD><B>MD203</B></TD><TD><l>249.95</lx/TD></TR> 
30 <TR><TD><B>MDR3</B></TD><TD><I>399.95</I></TD></TR> 
</TABLE> 
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<HR WIDTH=200 ALIGN=LEFT> 

</BODY> 

</TABLE> 



5 In the wrapper, the useful information starts from line 7 and ends at </TABLE>, 

so the Semantics Recognition Buyer Agent 20 will cut the useless information before 
extracting the model number and price. The HTML file, after header and trailer 
information are stripped away, is 

Number</TH><TH>PRICE(US$)</TH></TR> 
10 <TR><TD><B>HM381MD</B><TD><l>399.95</l></TDx/TR> 

<TR><TD><B>MD2070</B></TD><TD><l>599.95</l></TDx/TR> 

<TR><TD><B>MD203</B></TD><TD><I>249.95</Ix/TD></TR> 

<TRxTDxB>MDR3</Bx/TD><TDx|>399.95</lx/TD></TR> 

15 Then the Semantics Recognition Buyer Agent 20 will use pattern matching to 

extract the model number and the price of the product. In the wrapper, the pattern for 
the model number is <B>*</B> and the pattern for the price is </1>#</1>, where * 
represents the model number and # represents the price. The agent will firstly extract 
the model number HM381MD and compare it with the user's request model number 

20 "MD203." As it does not match, the Semantics Recognition Buyer Agent 20 looks for 
another model number until it finds the model number MD203. After the model number 
is found, the Semantics Recognition Buyer Agent 20 uses the price pattern to extract 
the first price after the model number. When the model number and price have been 
extracted, the Semantics Recognition Buyer Agent 20 stops extracting information from 

25 the page and put the information into a array called array jtemQ. 
Critical Section 

The arrayJtemQ is shared data for those N threads, and all the threads can 
access this member variable. There is a risk that more than one thread accesses the 
arrayjtemQ at the same time which causes an access violation. In order to protect this 
30 shared data in a consistent state, a critical section is used to prevent more than one 
thread from modifying the data at the same time. It is declared as, 
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CCriticalSection m_csDoor; 

Before inserting an element into the arrayjtem, the line 
m_csDoor,Lock(); 

is added which is used to start the critical section. All the variables inside the critical 
5 section will be locked to prevent other threads from accessing the particular variable. 
After finishing the insertion, the line 
m_osDoor.Unlock(); 

is added, which is used to state the end of the critical section. All the locked variables 
will be unlocked to allow other threads to access to the member variable. By doing so, 
10 the member variable of arrayjtem can be safely shared by all threads. 
Sorting the Price 

In a specified time interval, the array sortjtem which stores the product price will 
be sorted by a quick sort method. 

The quick sort method can be implemented as follows: 
15 IFIeft<rightTHEN 
BEGIN 

pivot := partition (list, left, right); 
Quicksort (list, left, pivot-1); 
Quicksort (list, pivot+1, right); 

20 END 

A "key" value of the structure is selected to be positioned in every recursion of 
the code. The function then repeatedly scans through the structure in two directions. 
Values less than the key are passed to the left side of the structure and those greater 
25 are passed to the right side. These "left to right" and "right to left" scans and swaps 
continue until a flag condition tells them to stop. 

Return Response to the User 

An HTML file is returned to the user which will be stored in the member variable 
m_output, and which displays the sorted results of the search conducted by the SRBA 

30 20. 

//String used to display content to browser 
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'define HTTP_HEADER "Content-type: text/htm\n\n" 
//Codes to display to browser 

Submitted with this application on the afore-stated compact disc is a computer 
5 program listing appendices which provide code sections which implement selected 
features of the present invention. In particular, in the portion labeled "3.1 The Learning 
Phase," source codes are provided for "3.1.1 Main COOSA Application Class" — the 
main class file for the COOSA application; for "3.1 .2 Add Vendor Class — adding a 
vendor class to the database; "3.13 COOSADoc Class" — invocation of the display of 

10 documents and screens for the Semantics Recognition Learner Interface; "3.1 .4 
COOSA View Class"— Learner Interface's and its function's screens; "3.1 .5 Training 
Data Class" — invocation of the Semantics Recognition Learner Agent; and "3.1.6 
Vendor Class" — Declaration of labeling algorithm to process through all vendor Web 
pages. In the portion labeled "Shopping Phase," source codes are provided for "3.2.1 

15 Agent Class" — declaration of the Semantics Recognition Buyer Agent; and "3.2.2 
Thread Process" — part of the Semantics Recognition Buyer Agent's process. 

Referring now to Figures 32 through 39, a GUI or Interactive-Agent-Character 
Shopper / Buyer interface for use in connection with the present invention will now be 
elaborated. In Figure 32, a simplified illustration of a "main menu" screen for a GUI or 

20 Interactive-Agent-Character Shopper / Buyer interface (IACS/BI) for use with the 

present invention. It is to be noted that there is a choice of "channels" (categories) of 
products provided for the user in the upper right hand corner of this "main menu" 
screen. A "Quick Search" feature is also provided in the left hand side of the screen. 
Right beneath it, there is a provided box in which an animated feature of self-typing 

25 instructs the online human user how to use the quick search option. The left hand 

screen panel also provides a set of boxes for member sing-in as a temporary trial or life 
member. (Note that most of the portal's functions of the present invention are disabled 
until the user authentication is validated.) At the bottom left hand corner is provided a 
set of links to online vendors that have been registered with the portal of the present 

30 invention whereas on the right, it can be observed that a big message box labeled 

"feedback" is provided for the online user to enter messages with comments through e- 
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mail to the e-mail server, preferably running the Outlook Express brand e-mail server of 
Microsoft Corporation. 

Figure 33 is a simplified illustration of a screen of a GUI or Shopper / Buyer 
Interface for use with the present invention in which companies are displayed in 
5 response to a "Government-to-Business" textual icon which has been clicked on a 
previous screen — not shown — by the online buyer / user. However, note that this very 
screen cannot function because these companies, or so-called Government-to- 
Business e-commerce service or platform providers currently restrict strictly for 
member's privilege the access to their Web servers' databases by incorporating an 
10 authentication security interface in entirely closed-connected computer networked 
environment. 

Figure 34 is a simplified illustration of a screen display of a GUI or Shopper / 
Buyer Interface for use with the present invention in which details are provided about a 
company selected by the user from among the choices provided after the user has 

15 clicked the "Advanced Search" option on the screen in Figure 33. Note that on this 

screen, the banner in the frame of the panel just right below the tabs of the five types of 
domains, the capitalized message "ADVANCED AGENTS ARE ON!" is observed. 
Besides, at the bottom of the screen, the user is provided with dialog boxes which can 
be filled-in for running a search using the Semantics Recognition Buyer Agent 

20 functionality provided by the present invention. Again, however, note that this very 

screen cannot function because this company, or so-called Government-to-Business e- 
commerce service or platform provider currently restricts strictly for member's privilege 
the access to their Web server's databases by incorporating an authentication security 
interface in entirely closed-connected computer networked environment. 

25 Figure 35 is a simplified illustration of a screen of a GUI or Shopper / Buyer 

interface for use with the present invention in which companies are displayed in 
response to "Business-to-Business" textual icon which has been clicked on a previous 
screen (not shown) by the online buyer / user. However, note that this very screen 
cannot function because these companies, or so-called Business-to-Business e- 

30 commerce service / platform providers currently restrict strictly for member's privilege 
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the access to their Web servers' databases by incorporating an authentication security 
interface in entirely closed-connected computer networked environment. 

Figure 36 is a simplified illustration of a screen display of a GUI or Shopper/ 
Buyer Interface for use with the present invention in which details are provided about 
5 companies selected by the user from among the choices provided after the user has 
clicked the "Advanced Search" option on the screen in Figure 35. 

Figure 37 is a simplified illustration of a screen of a GUI or Shopper / Buyer 
Interface for use with the present invention in which selected items and their 
descriptions are displayed in response to the user selecting the "Domain A" tab. 
10 Figure 38 is a simplified illustration of a screen display of a GUI or Shopper / 

Buyer Interface for use with the present invention in which vendors that are listed sell 
items in Domain A in response to the user who has clicked "Advanced Search" option 
on the screen in Figure 37. 

Figure 39 is a simplified illustration of a screen display of a GUI or Shopper / 
15 Buyer Interface for use with the present invention in which details are provided of the 
results of a search conducted using the Semantics Recognition Buyer Agents feature of 
the present invention. The Shopper / Buyer Interface responds to the user submitting a 
search request through the search parameters interface as shown at the bottom of the 
screen in Figure 38. 

20 It is to be further understood that while the present invention has been described 

in terms of the Internet and the World Wide Web, the present invention is equally 
suitable for use in recently introduced systems and next generation systems. To 
exemplify, the wireless application development tool, J2ME (Java to Micro Edition), can 
be used to incorporate the online intelligent multilingual- and -domain-independent price 

25 comparison capabilities into mobile/wireless platforms including all models of 3G or 
Web phones, Interactive and Ultimate TVs, pocket PCs, Palm organizers, all-in-one 
Web-enabled Palm Synchronizers, wireless tablets, etc for delivering to mobile workers 
and Netizens numerous products and multilingual value-added Business-Web services 
on a home page as point-of-access all in one-stop anywhere on a 24/7/365 basis. 

30 Furthermore, the present invention can be used to deliver via wired and 

mobile/wireless platforms various products and multilingual value-added Business-Web 
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services having such enablement and functions and features as price comparison, e- 
Wallet integration, Inter-Agent Communication with Negotiation Ability — Agent-to- 
Agent (A-to-A) contract-negotiation— real world simulation capabilities to multiple e- 
commerce segments, including Consumer-to-Business, Consumer-to-Consumer, and 
5 Business-to-Business auctions, Government-to-Business transactions, etc. These A-to- 
A commerce or A-commerce's activities will be constructed and activated on a Global 
Ensemble Marketplace Framework just-in-time in a dynamic fashion in combination with 
the use of either keyboard, mouse, and pointing device. 

In the following sections, further information is provided about Java-based and 
10 mobile implementations of the invention, as well as improvements in searching 
configurations. 

User Interface: 

The present invention provides a real-time automated worldwide portal whereby 
online users can conduct multilingual and non-multilingual character searches to view 

15 hyper-linked third party vendor Websites and their online catalogues through the World 
Wide Web and Internet, using wireless or hardwired, or other devices, to obtain 
products and services information in any field, images and summaries, price-product- 
ratings comparisons, and their feature comparisons. An automated assistant zaps out 
across national boundaries for searching and extracting a desired keyword product and 

20 zaps back with the best price for a product, its thumbnail, and its brief description, and 
display them on result pages. 

Referring now to Figure 40, the Quick Search and Advanced Search provided in 
accordance with the present invention will be briefly described. Figure 40 illustrates the 
Main Page of the user interface as it may appear on a desktop or laptop or other 

25 display. Preferably, this embodiment of the invention may be accessed through Internet 
Explorer (IE) 4.0 or above, manufactured by Microsoft Corporation. 

After the IE is opened on the user's system, the user types in the URL at which 
the portal is located, for example http://www.coolsa.com. A home page similar to that 
shown in Figure 40 will then appear. The user then clicks on a tab, such as the 

30 "Domain A" tab, which may correspond to a domain such as "Electronics / Any 
Products," and the page for Domain A, appears such as illustrated in Figure 40. 
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Quick Search: 

To perform a Quick Search the user need only enter a keyword and select a 
country to search for a product. As indicated in the left hand column of Figure 41, the 
user selects a country where the vendors of interest are located, types in a keyword, 
5 such as "mp3", into the "Keyword" box, and then clicks GO! or hits Enter (on the 
keyboard) to start the search. 

In response to the search query, the system returns a Results Page such as 
shown in Figure 42, containing the results of the search for the keyword entered earlier. 
As can be seen From Figure 42, the Search Results identify the keyword (shown as 
10 "XXX" in Fig. 42), and the number of items found (shown as "NNN" in Figure 42). Also 
provided for each item are a thumbnail picture of the item, a description of the item, the 
"store" where the item was found, and the price. 

The thumbnail or product description or "buy now" preferably provide hyperlinks 
to view further detail on online vendor search result page(s). A hyperlink of the store is 
15 provided to permit the user to view the home page of the vendors Website. 

Advanced Search: 

Also provided is an Advanced Search function that is invoked by clicking the 
hyperlink "Advanced Search" in the upper right hand corner of the page, such as shown 
in Figure 42. In response, the Advanced Search page appears as shown in Figure 43. 
20 The user then chooses in the "Your country/Locale" box a country where the 

vendors of interest reside. The Advanced Search page displays vendors in the selected 
country. 

The user then clicks the checkmark boxes for one or more desired stores. (If 
none of the stores are clicked, the default will extract and display search results for all 
25 vendors.) The user may also enter a "Time out" if required; and "Price Ranges," if 
required. The user also enters a Keyword, which is mandatory. 

After the user hits Enter or clicks "go" to start the search, a search result page 
appears, similar to that shown in Figure 42, and with similar information and links. 
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II 

Exemplary Implementation: 

Preferably this embodiment of the present invention is implemented using a 

J2EE Servlet / JSP Engine: Tomcat 4, a Backend Database: Firebird 1 .0, Java: Sun 

JDK 1.4, Framework: Struts 1.1, and Build Tool: Ant 1.5. 
5 This embodiment provides an administration console, which enables 

administrators to perform maintenance tasks including: add/edit country information; 

add/edit vendor information; and train/edit vendor description. 

A Struts framework is employed to model the Server-side implementation of a 

MVC architecture using a combination of Java Bean, JSP's, custom JSP tags, and Java 
10 servlets. The MVC (Model-View-Controller) architecture is a way of decomposing an 

application into three parts: the model, the view and the controller. 

Model 

A model represents an application's data and contains the logic for accessing 
and manipulating that data. Any data that is part of the persistent state of the application 

15 should reside in the model objects. The services that a model exposes must be generic 
enough to support a variety of clients. By glancing at the model's public method list, it 
should be easy to understand how to control the model's behavior. A model groups 
related data and operations for providing a specific service; these group of operations 
wrap and abstract the functionality of the operation being modeled. A model's interface 

20 exposes methods for accessing and updating the state of the model and for executing 
complex processes encapsulated inside the model. Model services are accessed by the 
controller for either querying or effecting a change in the model state. The model 
modifies the view when a state change occurs in the model. 

View 

25 The view is responsible for rendering the state of the model. The presentation 

semantics are encapsulated within the view. Therefore, model data can be adapted for 
several different kinds of clients. The view modifies itself when a change in the model is 
communicated to the view. A view forwards user input to the controller. 
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Controller 

The controller is responsible for intercepting and translating user input into 
actions to be performed by the model. The controller is responsible for selecting the 
next view based on user input and the outcome of model operations. 

5 Controller Object 

The controller object promotes a cleaner division of labor for the controller layer 
that typically deals with view and navigation management, leaving the model access 
and manipulation to request handlers that are typically request specific. All incoming 
requests are mapped to the central controller in the deployment descriptor as follows: 



<servlet> 

<servlet-name>action</servlet-name> 

<servlet-class>org.apache.struts.action.ActionServlet</servlet-class> 
<init-param> 

<param-name>config</param-name> 

<param-value>/WEB-INF/struts-config.xml</param-value> 
</init-param> 
<init-param> 

<param-name>debug</param-name> 

<param-value>0</param-value> 
</init-param> 
<init-param> 

<param-name>detail</param-name> 

<param-value>0</param-value> 
</init-param> 

<load-on-startup>2</load-on-startup> 
</servlet> 

All request URL's with the pattern *.cgi are mapped to this servlet in the 
deployment descriptor as follows: 



15 



<servlet-mapping> 

<servlet-name>action</servlet-name> 

<url-pattern>*.cgi</url-pattern> 
</servlet-mapping> 

A request URL that matches this pattern has the following form: 
http ://www. coo I sa . com/xxx/xxx . eg i 
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The logical mapping of resources depicted above permits modification of 
resource mappings within the configuration file without the need to change any 
application code; this mapping scheme is also referred to as Mulitplexed Resource 
Mapping. The controller provides a centralized access point for all presentation-tier 
requests. Meanwhile, the controller delegates each incoming request to the 
RequestProcessor that in turn dispatches the request to the associated form bean for 
form validation, and to a request handler for accessing the model. The combination of 
controller and RequestProcessor forms the core controller process. The abstraction 
provided by the controller alleviates a developer from creating common application 
services like managing views, sessions, and form data; a developer leverages 
standardized mechanisms such as error and exception handling, navigation, 
internalization, data validation, data conversion, and etc. 

The Dispatcher Object 

The RequestProcessor functions as a dispatcher and handles client requests by 
15 instantiating (or reusing) a request handler, and a corresponding form bean. The errors 
created, or exceptions thrown by the form beans and the request handlers are 
processed by the RequestProcessor that influences the view management function of 
the RequestProcessor. Form beans assist the RequestProcessor in storing the form 
data and/or staging intermediate model data required by the view. The 
20 RequestProcessor uses the <action> declarations in the struts-config.xml file, as 
illustrated below, for instantiating request-specific request handlers. 

<form-beans> 

<form-bean name="searchForm" type="com.coolsa.shopper.SearchForm" /> 
<form-bean name-VendorForm" type-'com.coolsa.vendor.VendorForm" /> 

</form-beans> 

<action path=7Search M 

type="com.coolsa.shopper.SearchAction" 
name-'searchForm" scope-'request" validate="false"> 
<forward name-'success" 

path=7pages/searchResult.dhtml" redirect-'false" /> 
<forward name="fair path=7pages/searchltem.dhtmr redirect= n true" /> 
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</action> 



<action path=7Vendor" 

type= ,, com.coolsa.vendor.VendorAction" 
name-'vendorForm" scope="request" 
parameter= ,, method ,, validate="faise"> 

<forward name =,, success" path=7advance.dhtmr redirect =,, false" /> 
<forward name="fair path=7pages/vendor.dhtml" redirect-'true" /> 

</action> 



All incoming requests are delegated by the controller to the dispatcher that is the 
RequestProcessor object. 

Command Pattern using ActionMappinq 

5 The embodiment being described uses a declarative way of specifying the 

mapping between the servlet path in the request URL and an appropriate request 
handler using XML syntax. This implementation is very similar to the command pattern. 
The following snippet is from struts-config.xml file. These declarations are used for 
creating an ActionMapping configuration object, which is the runtime representation of 

10 the <action> element. 



<action-mappings> 
<action path=7Welcome" 

type =,, org.apache.struts.actions.ForwardAction" 
parameter=7pages/index.dhtml" /> 

<action path=7Search" 

type= M com.coolsa.shopper.SearchAction n 

name= ,, searchForm" 

scope="request" 

validate="false"> 

<forward name="success" 

path=7pages/searchResult.dhtml" redirect="false" /> 
<forward name-fair 

path=7pages/searchltem.dhtml" redirect="true" /> 

</action> 
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</action-mappings> 



The attributes used in the preceding declaration are defined as follows: 
"path" - the context relative path in the HTTP request that is used for identifying 
this action mapping. 

5 "type" - class name that will be used for creating an instance of the request 

handler for handling this request. 

"name" - the logical name of a JavaBean, also called a form bean, that will be 
used to hold form data. The form bean will be saved in the specified scope using this 
name. 

10 "scope" - request or session scope for saving the form bean. 

Shopper 

Figure 44 provides a flowchart that depicts the detailed application logic of 
Shopper/Shopping Agents in accordance with the present invention. In particular, when 
a shopping request is received, 4410, the input data in the request is parsed in 4412. 

15 Based upon the parsed data, vendor information is retrieved from a database (4414), 
and a shopping agent is created, 4416. Each of the shopping agents created then 
sends a request to its corresponding vendor (4418). Then, based upon vendor delimiter 
information from the database, the information returned in response to the shopping 
agent requests are checked for valid information (4420), and the valid information is 

20 then accumulated until either a time out has occurred or all shopping agents have 

returned information (4422). Thereafter, the valid information is sorted (4424) and then 
incorporated into an HTML and returned to the user in a results page. 

Learner 

Figure 45 depicts the detailed application logic of Learner Agent in accordance 
25 with the present invention. First, upon receipt of a request to "learn" a vendor, the 
Learner Agent is invoked (4512) and initialized (4514). Vendor information is then 
retrieved from the database (4516), and training examples are also retrieved (4518). 
Connection is then made to the vendor website to collect further training pages (4520). 
Once additional training pages have been retrieved from a vendor website, the pages 

Gray Cary\SF\3098970.2 -69- 
2102680-991000 



•f 

are parsed to identify delimiter candidates for product and price (4522, 4524, 4526, 
4528), and then feasible price and product delimiters are learned (4530, 4532, 4534), 
and then the best delimiter combination is determined (4536). This information is then 
saved and used to update the vendor description information (4538). 

5 Add Country 

Figure 46 provides information about the country information fields maintained by 
the present invention, including the name of the data field, a description of the 
information kept in the data field, and the allowed values for the data field. Referring to 
Figure 47, the process for adding country information is illustrated. The operations 

10 provided in the Add Country module include the following: 

"Map getAIICountriesO" - retrieves all countries from database. Figure 48 
illustrates the screen provided at the Administration Console in connection with the 
"Map getAIICountriesO" operation. In the upper right hand corner of the screen, the 
"Country" link is used to call up this country list. By clicking on a particular country in 

15 the "Country ID" column, the "Country getCountry(String countrylD)" operation is 

invoked, which retrieves a specific country given its country ID. Figure 49 illustrates the 
screen which appears on the Administration Console in response to "Country 
getCountry(String countrylD)". This screen shows the existing detail for the selected 
country, and permits the operator to edit the country information fields for the selected 

20 country. The Country Name or Encoding can be modified if required. The operator may 
type in a correct country name option and/or Select a correct Encoding option from a 
pull-down list or, select from correct existing countries from a pull-down list. The 
operator may click Save to save the modified country information or click Cancel to 
cancel the modified country information. Upon clicking Save, the "int 

25 updateCountry(Country country)" operation is invoked which updates the country 
information in the database. 

If at the screen in Figure 48, the operator wishes to Add a country, the Add 
button in the upper right hand corner of the List of Countries table would be clicked. 
This would invoke the "int addCountry(Country country)" operation which adds a new 

30 country to database. This brings up the screen shown in Figure 50. The operator then 
types in a new country name option or selects one of the existing countries from the 
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pull-down list. Then, the operator selects one of the existing encoding data fields from 
the pull-down list. The operator then clicks Save to save the added country information 
option or clicks Cancel to cancel the added country information. 

In the List of Countries table of the screen shown in Figure 48, the operator may 
5 also click a Delete button under the Action column to delete an existing country. This 
invokes the "int deleteCountry(String countrylD)" operation which deletes an existing 
country from the database given its country ID. 

Add Vendor 

Figure 51 provides information about the vendor information fields maintained by 

10 the present invention, including the name of the data field, a description of the 

information kept in the data field, and the allowed values for the data field. Referring to 
Figure 52, the process for adding vendor information is illustrated. "Vendor" is an online 
store to allow online users/buyers to buy products on its Website. In the Administration 
Console, "Vendor" consists of vendor information, training examples, and vendor 

15 descriptions. Figure 53 illustrates the Administration Console screen that appears 
when the Vendor link is clicked in the upper right hand corner of the Console. This link 
invokes the "Map getAIIVendor()" operation which retrieves all vendors from database. 
Note that the fields described in Figure 51 are displayed in this screen, and the "All 
Countries" selection is displayed in the pull down window in the upper left hand corner 

20 of the "List of Vendors" table. 

Vendors can be filtered by country by selecting one of the countries on the pull- 
down list beside the "List of Vendors". This invokes the "Map 
getVendorByLocale(String locale)" operation which retrieves vendors given a specific 
locale. An example of this operation for the United States as the selected locale is 

25 illustrated in Figure 54. 

By clicking the Vendor ID of a particular vendor - the underscored number which 
appears in the "Vendor ID" column in Figures 53 or 54 - the operator is able to view the 
details for the selected vendor. This invokes the "Vendor getVendor(String vendorlD)" 
operation that retrieves a vendor given vendor id. The Existing Details of the Vendor 

30 screen/page appears as shown in Figure 55. 
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The Existing Details for a vendor can be edited by clicking on the edit button in 
the "Vendor Information" table of the Vendor Details screen shown in Figure 55. This 
invokes the "Vendor getVendorByName(String name)" operation that retrieves a vendor 
given the vendor name, and displays the screen shown in Figure 56. The operator can 
5 then modify Vendor Name, Description, Vendor URL, Form URL, Country and 
Currency fields, if required. The operator may then click Save to save the modified 
vendor information option or click Cancel to cancel the modified vendor information. 
This invokes the "int updateVendor(Vendor vendor)" operation which updates the 
vendor information in the database. 

10 If the operator desires to add a vendor, the Add button in the upper right hand 

corner of the screen of Figure 54 is clicked, and the "String addVendor(Vendor vendor)" 
operation is invoked that adds a vendor and returns its vendor id. Figure 57 provides an 
example of the screen that is displayed in the Add Vendor operation. The operation 
permits the operator to type in a new vendor name, type in a Description (a brief 

15 description of the vendor's line of business), type in its vendor URL, type in its Form 
URL, select one of the Countries from the pull-down list, and to select one of the 
Currencies from the pull-down list. The operator may then click Save to save added 
new vendor information or click Cancel to cancel added new vendor information. 
If the operator desires to delete a vendor from the Vendor List, this is 

20 accomplished in the Vendor Details screen shown in Figure 55. The operator clicks the 
Delete button in upper right hand corner of the "Vendor Information" table. This invokes 
the "int deleteVendor(String vendorlD)" operation that deletes a vendor from database. 

Learning 

Returning now to Figure 55, it can be seen that two other tables or screens are 
25 displayed in the Administration Console for the Vendor Details page in accordance with 
the present invention - "Training Example" and "Vendor Description". The "Training 
Example" is the example of the information sought out in a training operation that is 
used to learn the information to be included in the "Vendor Description." The "Vendor 
Description" provides information about the head, tail and delimiter characteristics used 
30 in a vendor's webpages. 
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The "Training Examples" fields used in the embodiment of the invention being 
described include: 



Data Field 


Description 


Allowed Value 


Example ID 


Training Example ID 


System Generated 


Search Word 


Search key word 


Any 


Product Name 


Training example name 


Any 


Price 


Training example price 


Numeric 



5 The Training Example module maintains the training examples for the Learner 

function. When the "Vendor" link in the Administration Console (see upper right hand 
corner of Figure 48, for example) is clicked, the "Map getTrainingExamples()" operation 
is invoked that retrieves all training examples and provides the "Training Example" 
screen in Figure 55. 

10 The "Map getTrainingExamples(String domainID, String vendorlD)" operation 

may also be invoked that retrieves training examples given the domain id and vendor id, 
so that training examples are displayed which are filtered by the selected product 
domain and selected vendor. 

In the "Training Examples" screen shown in Figure 55, one of the Example ID'S is 

15 10019. This is the ID assigned to the vendor for which training Vendor Information has 
been gathered. The search word used to gather such information was "Tablet PC," and 
the particular product in connection with which the information was gathered was the 
"Compaq Table PC TC1000." The price information that was gathered is also specified. 
If the operator clicks on the Example ID number, for example 10019 in Figure 55, 

20 the "TrainingExample getTrainingExample(String examplelD)" operation is invoked that 
retrieves a training example given the training example id - in this case, for 10019. 

If the operator clicks on the Add button in the screen of Figure 55, the "String 
addTrainingExample(TrainingExample trainingExample)" operation is invoked that adds 
a training example to database, and returns its id. Figure 58 illustrates the Add Training 

25 Example screen which is used for operator input for a new training example. The 
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operator can type in a search word (e.g., MP3) in the "Search Word" field, a product 
name/model in the "Product Name" field, and a corresponding price in the "Price" field. 
The operator clicks Save to save an added new training example option or clicks Cancel 
to cancel added new training example. The operation returns an Example ID for the 
5 new Training Example When the operator clicks Save, the "int 

updateTrainingExample(TrainingExample trainingExample)" operation is invoked that 
updates the training example information in the database. 

If the operator desires to delete a training example, the "Delete" button in the 
"Action" column of the Training Example screen in Figure 55 is clicked to invoke the "int 
10 deleteTrainingExample(String examplelD)" operation that deletes a training example 
given its id. 

Vendor Description 

Returning to Figure 55, the "Vendor Description" screen at the bottom of the 
figure illustrates the information gathered for each vendor in connection with this 
15 embodiment of the present invention. Preferably, the Vendor Description includes the 
delimiters used in a vendor's webpages that will permit the present invention to locate a 
product and its corresponding price listed on the online catalogue of an online vendor 
store. The Vendor Description fields maintained in the preferred embodiment of the 
present invention include the following: 



Data Field 


Description 


Allowed Value 


Head 


Ceiling of the valid content 


Numeric 


Tail 


Floor of the valid content 


Numeric 


Item Left Delimiter 


Left delimiter of the 
product description 


Any 


Item Right Delimiter 


Right delimiter of the 
product description 


Any 


Price Left Delimiter 


Left delimiter of the price 


Any 


Price Right Delimiter 


Right delimiter of the price 


Any 
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If the operator wishes to edit the Vendor Description as illustrated in Figure 55, 
clicking on the Edit button of the Vendor Description Screen will cause the Edit Vendor 
Description screen shown in Figure 59 to appear. The operator may then modify the 
5 Item Left Delimiter, the Item Right Delimiter, the Price Left Delimiter, or the Price Right 
Delimiter, if required. The operator may then click Save to save the modified delimiters 
option or click Cancel to cancel the modified delimiters. 

Returning to Figure 55, if the operator wishes to have the system "learn" a new 
Vendor Description, the operator clicks the "Learn" button in Vendor Description screen 
10 of Figure 55, and the process illustrated in Figure 45 is invoked. Among the operations 



invoked during this process are the following: 



Operation 


Description 


int learn(String domainID, String 
vendorlD) 


Trains vendor description given vendor 
id and its domain 


ArrayList getAIICandidates(String page, 
String example, int leftOrRight) 


Generates a list of delimiter candidates 
given the training page, training 
example and delimiter type 


Map getTrainingResults() 


Retrieves all training results 


Map getTrainingResults(String 
domainID) 


Retrieves all training results given a 
domain id 


TrainingResult getTrainingResult(String 
domainID, String vendorlD) 


Retrieves training results given a vendor 
and its domain id 


int addTrainingResult(TrainingResult 
trainingResult) 


Adds a new training result to database 


int deleteTrainingResult(String 
domainID, String vendorlD) 


Deletes an existing result given domain 
id & vendor id 


int updateTrainingResult(TrainingResult 
trainingResult) 


Updates an existing training result 



Figure 65 is an illustration of the screen that appears on the Administration 
Console while the system is learning a vendor site in accordance with the process of 
15 Figure 45. 

Returning to Figure 40, if the operator wishes to have the system "shop" for an 
item identified by Keyword, the process illustrated in Fig. 44 is invoked. This launches 
an intelligent software robot that actually visits vendors' Websites to collect shopping 
information. The process uses the Vendor Description described above in connection 
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with Figure 55 to parse the collected contents for shopping items. Among the 
operations invoked during this process are the following: 



Operations 


Description 


ShopperAgent(List searchlnfoList, String 
search Keyword) 


Constructor used to construct a 
shopper agent instance 


void setSessionTime(long sessionTime) 


Sets the maximum session time 


Map searchQ 


Performs searching 






Map search(String localeld, String 
domainID, StringQ vendorlD, String 
keyword, String frPrice, String toPrice, 
String timeout) 


Search for shopping items based on 
any of following criteria: 

• Search by locale 

• Search by vendor 

• Search by locale and domain 

• Search by vendor and domain 



Mobile Implementation 

5 The present invention includes a mobile application that provides the shopping 

capabilities of the present invention by way of the wireless Internet by displaying real- 
time search results of price-product comparison, on mini-screen panel of J2ME-enabled 
or 3G cell phones and handheld devices, of any vendors across national boundaries via 
interface with the Shopper Agent of COOLSA Server side in order to promote 

10 unprecedented online international trade. 

Referring now to Figure 60A, following a mobile users' connection to the website 
which implements the present invention, the user is presented with a Search Menu. In 
order to search for items, online users can choose the country where the vendors to be 
searched are located. As shown for the embodiment illustrated in Figure 60B, when 

15 "Country" is selected, this brings up a Country Menu which lists the countries for those 
vendors for which information is maintained in an offline database at the server side. 
The default country in this embodiment is the "United States." In the bottom right hand 
corner of the screen shown in Figure 60B a "Choose" button is provided by which the 
highlighted country can be selected. 

20 Next, as illustrated in Figure 61 A, "Product" is selected from the Search Menu 

screen. This causes a Search Form screen to appear, as illustrated in Figure 61 B. This 
allows online users to search for a product by only entering a keyword. The user then 
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enters a keyword, such as "LCD", as shown in Figure 61 C in a Keywords screen. When 
the keyword has been entered, the user then presses the Search button, as shown in 
Figure 61 D, to launch the search. 

Figure 61 E illustrates the form of results which are returned following completion 
5 of a search. The user can then browse the items by using the UP or DOWN buttons of 
the handheld device. The user can choose an item from the search results and press 
the "Detail" button to obtain further details about an item, as illustrated in Figure 61 F. 
The "Back" button can be used to return to the list of item search results. 

Mobile Application 

10 Preferably the mobile embodiment of the present invention is implemented using 

J2ME Library: MIDP 1.0, J2EE Servlet / JSP Engine: Tomcat 4, Backend Database: 
Firebird 1 .0, Java: Sun JDK 1 .4, Framework: Struts 1.1, and Build Tool: Ant 1 .5. 

This embodiment enables users to buy/shop online with cross-national-boundary 
selections for promoting in real-time online international trade through all J2ME-enabled 
15 and/or 3G cell phones and handheld devices, for example. 

In accordance with this embodiment of the present invention, the Mobile client is 
built on J2ME platform. It communicates with the Server by HTTP protocol and XML. 

Advantages of using J2ME as a mobile applications development tool are twofold 
as follows: 

20 (1 ) Server detects the client as a mobile application and returns XML instead of 

JSP. In Server side, only model objects need to be changed. 

(2) The benefit of the design is that the underlying Application in the Server side 

need not to be changed to handle different kind of clients. 

Java 2 Micro Edition (J2ME) is a platform for developing applications for 
25 handheld devices. Within J2ME, configurations define the run-time environment for a 

set of devices by specifying the Java features that are available, as well as which virtual 

machine will be used. In J2ME, the Connected Limited Device Configuration (CLDC) 

defines a configuration targeted at devices that have limited processing power, display 

and memory. The majority of these devices also are mobile. 
30 Meanwhile, on top of configurations are profiles. Profiles provide API's for user 

interface design, network support, and persistent storage. The Mobile Information 

Gray Cary\SF\3 098970.2 -77- 
2102680-991000 



Device Profile (Ml DP) is a set of Java APIs which, together with the CLDC, provides a 
complete J2ME application run-time environment targeted at handheld devices, such as 
cell phones, pagers and entry level PDA's. 

To integrate the wireless J2ME mobile applications, HTTP and XML — 
specifically kXML — are used to be the integrated point between Client side and Server 
side. 

For HTTP, the mobile application posts the request with "requestSource=mobile" 
to the Server, which lets the Server know that the client is a mobile application. Thus, 
the Server returns XML instead of JSP. 

For the XML, the client side uses kXML while Server side uses JDOM. 
Since Ml DP does not provide native support for XML parsing, kXML is used as 
the XML parser. It provides a non-validating XML pull parser and writer targeted 
specifically at the MIDP platform. The minimal kXML JAR file handles/weighs in at 21 
kilobytes, with the complete kXML JAR (including kDOM and WBXML) at 37 kilobytes. 

A pull model is provided so that the code for processing state can be 
implemented in a natural and efficient manner using local variables and recursions. 

Select Country 

Figure 62 illustrates the model used for the Select Country function of the mobile 
implementation. 

20 The data fields for the Country information include "Country ID," which is a 

unique ID; a "Name," which is the country's name; and "Encoding," which is the MIME 
Type. 

The kXML wrapper codes as XML parser for encoding Select Country are of the 
following form: 

25 

<?xml version="1.0" encoding="ISO-8859-1"?> 
<Countries> 

<Country id="Africa H > 
<Name>Africa</Name> 
<Encoding>8859_1 </Encoding> 
</Country> 

<Country id="Belgium M > 
<Name>Belgium</Name> 
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<Encoding>8859_1 </Encoding> 
</Country> 



</Countries> 

Referring now to Figure 63, the model used in this embodiment for searching for 
an item, is illustrated. 

The encoding for the Search Item data fields include "Item ID" which is a unique 
5 ID for the item; "Vendor Name" which is the name of the vendor; "Vendor URL" which is 
the URL for the vendor; "Description" which is the item description; and "Price" which is 
the price for the time. 

The kXML wrapper codes as XML parser for displaying the above search results 
on the mini-screen panel of cell phones or handheld devices after interface with the 
10 Shopper Agent of the underlying application are of the following form: 



<?xml version="1.0" encoding="ISO-8859-1"?> 
<ltems> 

<ltem id="1"> 
<Vendor> 

<Name>Brandsmall.com</Name> 
<Url>http://www.brandsmall.com</Url> 
</Vendor> 

<Description>Coby® Personal MP3/CD Player w/Anti-Shock Model 
MPCD500</Description> 
<Price>99.98</Price> 
</ltem> 
<ltem id="2"> 
<Vendor> 

<Name>Brandsmall.com</Name> 
<Url>http://www.brandsmall.com</Url> 
</Vendor> 

<Description>RCA® Kazoo Portable MP3 Digital Player Model 
RD1 000</Description> 
<Price>84.99</Price> 
</ltem> 



</ltems> 
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Remote Deployment: 

The following is an example of how a wireless application of the present 
invention can be deployed remotely. First the "*.jar" and "*.jad" files which implement 
the remote interface between the handheld devices and the Server are uploaded to a 
5 remote web server. 

The remote web server is then reconfigured so that it recognizes JAD and JAR 
files: (1 ) for the JAD file type, set the file extension to .jad and the MIME type to 
text/vnd.sun.j2me.app-descriptor; for (2) for the JAR file type, set the file extension to 
.jar and the MIME type to application/java-archive. 
10 For the Tomcat J2EE Servlet/JSP Engine, the web.xml file is configured as 

follows: 

<mime-mapping> 

<extension>jad</extension> 

<mime-type>text/vnd.sunJ2me.app-descriptor</mime-type> 
15 </mime-mapping> 
<mime-mapping> 

<extension>jar</extension> 

<mime-type>application/java-archive</mime-type> 
</mime-mapping> 

20 

The JAD file's MIDIet-Jar-URL property is then changed to specify the URL of a 
JAR file. For example, in the copy of "*.jad" that was uploaded to the server, the 

"MIDIet-Jar-URL: coolsa.jar" 
25 is changed to... 

"MIDIet-Jar-URL: http:/A'ourWebServerAddress:port/pathTo/coolsa.jar ,, . 

To determine whether the application deployed correctly, open an ordinary web 
browser and enter the JAD file's URL. The J2ME Wireless Toolkit's default emulator 
30 should appear and the remotely deployed application should run in it. 
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J2ME-enabled devices (the Motorola/Nextel i85s, for example) include a Java 
Application Manager (JAM) responsible for downloading, installing, and configuring 
applications. The J2ME Wireless Toolkit includes a sample JAM that can run in the 
default emulator. To see how the user will download and manage the application, open 
5 a command prompt, change the current directory to <toolkit>/bin, and enter the 
command: 

emulator -Xjam 

The emulator appears and the JAM'S main screen will be visible. Figure 64A 
illustrates the appearance of the main screen in version 1 .0.4 of the toolkit. Select the 
10 Install soft button and at the prompt for the application's URL, as shown in Figure 64B, 
enter the URL of a web page that contains a hyperlink to the application's JAD file. 

Entering a long URL into a wireless phone is inconvenient. A faster and easier 
way to get started is to use a command in the form: 

15 emulator -Xjam:install=http://yourWebServerAddress:port/*.jad 

where *.jad is the name of the application file. 

Without further entry, the JAM downloads the JAR file specified in the JAD file 
and installs the application. The next time the emulator is started, simply select the 
20 JAM's Menu button, then use the menu to run the application, remove it, or perform the 
other functions shown in Figure 64C. 

It is important to note that this syntax allows the installation of only one Ml Diet at 
a time. Entering a URL allows the viewing of a web page that may contain several 
MIDIets to choose from. As an example, consider the following HTML file (midlets.html) 
25 that contains links to three JAD files: 
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<html> 
<head> 

<title>Midlets</title> 
</head> 

5 

' <body> 

Download midlets: 
<P> 

10 <a href= M http://1 27.0.0. 1 :8080/coolsa.jad">Coolsa.jad</a> 

</body> 
</html> 

It is important to note that the hyperlinks point to the application's JAD file. Now, 
15 enter the URL into the install window as shown in Figure 64D. (The IP address 
127.0.0.1 is equivalent to localhost.) 

The JAM reads the HTML doccument (midlets.html), parses the hyperlinks, and 
displays a list of MIDIets that can be downloaded, as shown in Figure 64E. Now the 
MIDIet to download can be selected. The JAM reads the JAD file to discover whether 
20 the device is capable of handling the application. If so, it downloads and installs the JAR 
file specified in the JAD file. 

Once the MIDIet for the application is downloaded and installed, a display similar 
to Figure 64F will appear, which will include the mobile application of the present 
invention. Preferably the "*.jad" application is the MIDIet suite that comes with the 
25 J2ME Wireless Toolkit. 

Figure 64G shows a screen displayed by the JAM which notifies a user that a 
MIDIet the user is attempting to install is already on the device. However, this also 
allows the user to install an updated version of the MID let. 

Appendix A is a listing of handheld devices which are believed suitable for use in 
30 deployment of the mobile embodiment of the present invention. 

The terms and expressions which have been employed herein are used as terms 
of description and not of limitations, and there is no intention, in the use of such terms 
and expressions of excluding equivalents of the features shown and described, or 
portions thereof, it being recognized that various modifications are possible within the 
35 scope of the invention claimed. 
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APPENDIX A 



Manufacturer 


Model 


Wireless 
Technology 


Freq. 

(IVInZ; 




Software 


Screen 


Ava 


Casio 


A3012 
CA 


CDMA2000 
1X 


800 


MIDP 


1.0, CLDC 1.0 


132x176/14 bits 


Yes 


Casio 


r*A cor* 

A 


OUMM 


oUU 


MlUr 


I ,U, ULUU 1 .U 


IZUX lOO/O DHS 


xes 


Hitachi 


C3001 
H 


CDMA 


800 


MIDP 


1.0, CLDC 1.0 


120x162/12 bits 


Yes 


Hitachi 


C451H 


CDMA 


800 


MIDP 


1.0, CLDC 1.0 


120x143/8 bits 


Yes 


Kyocera 


C3002 
K 


CDMA 


800 


MIDP 


1.0, CLDC 1.0 


120x160/16 bits 


Yes 


LG Electronics 


C-nain 
2000 


CDMA2000 
1X 


800 


MIDP 


1.0, CLDC 1.0 


120x133/8 bits 


Yes 


LG Electronics 


C-nain 
2100 


CDMA2000 
1X 


800 


MIDP 


1.0, CLDC 1.0 


8 bits 


Yes 


LG InfoComm 


LX5350 


AMPS, 

CDMA2000 

1X 


800, 
1900 


MIDP 


1 .0, CLDC 1 .0 


120x198/16 DltS 


Yes 


LG InfoComm 


VX1 


AMPS, 

CDMA2000 

1X 


800, 
1900 


MIDP 


1 .0, CLDC 1 .0 


A OOt« A f\ A 

128x104 


Yes 


Mitsubishi 


J-D05 


PDC 


1500 


MIDP 


1.0, CLDC 1.0 


12 bits 


Yes 


Motorola 


A388 


GSM/GPRS 


900, 

1800, 

1900 


MIDP 


1.0, CLDC 1.0 


2 bits 


Yes 


Motorola 


Accom 
M 

008/62 
88 


GSM/GPRS 


900, 
1800 


MIDP 


1.0, CLDC 1.0 


320x240/2 bits 


Yes 


Motorola 


Accom 
pii uuy 


GSM/GPRS 


900, 

louu, 

1900 


MIDP 


1.0, CLDC 1.0 


240x160/8 bits 


Yes 


Motorola 


i50sx 


iDEN 


800 


MIDP 


1.0, CLDC 1.0 


111x100/2 bits 


Yes 


Motorola 


i55sr 


iDEN 


800 


MIDP 


1.0, CLDC 1.0 


111x100/2 bits 


Yes 


Motorola 


180s 


iDEN 


800 


MIDP 


1.0, CLDC 1.0 


119x64/1 bit 


Yes 


Motorola 


185s 


iDEN 


800 


MIDP 


1.0, CLDC 1.0 


111x100/2 bits 


Yes 


Motorola 


i90c 


iDEN 


800 


MIDP 


1.0, CLDC 1.0 


111x110/2 bits 


Yes 


Motorola 


i95cl 


iDEN 


800 


MIDP 


1.0, CLDC 1.0 


120x160/8 bits 


Yes 


Motorola 


T280i 


GSM/GPRS 


900, 

1800, 

1900 


MIDP 


1.0, CLDC 1.0 




Not 

yet 


Motorola 


T720 


GSM/GPRS 


900, 

1800, 

1900 


MIDP 


1.0, CLDC 1.0 


120x160/12 bits 


Not 
yet 


Motorola 


T720 


AMPS, 


800, 


MIDP 


1.0, CLDC 1.0 


120x160/12 bits 


Not 



GrayCary\SF\3098970.2 
2102680-991000 



APPENDIX A 



Manufacturer Model 



Wireless 
Technology 

CDMA2000 
1X 

Motorola V60i GSM/GPRS 



Motorola V60I 



Motorola V60i 



Motorola V66i 



Nokia 
Nokia 
Nokia 
Nokia 
Nokia 

Nokia 

Nokia 
Nokia 

Nokia 

Nokia 

Nokia 

Nokia 

Nokia 



3410 
35101 
3530 
3570 
3585 

3585i 

3590 
3650 



AMPS, CDMA 
AMPS, TDMA 
GSM/GPRS 

GSM 

GSM/GPRS 

GSM/GPRS 

CDMA2000 
1X 

AMPS, 

CDMA2000 

1X 

AMPS, 

CDMA2000 

1X 

GSM/GPRS 
GSM 



5100 GSM/GPRS 



6100 GSM/GPRS 



6200 GSM/GPRS 



6310i GSM/GPRS 



6610 GSM/GPRS 



Freq. 
(MHz) 

1900 



900, 

1800, 

1900 

800, 
1900 

800, 
1900 

900, 

1800, 

1900 

900, 
1800 

900, 
1800 

900, 
1800 



Software 



Screen 



850, 
1900 

900, 

1800, 

1900 

900, 

1800, 

1900 

900, 

1800, 

1900 

850, 

1800, 

1900 

900, 

1800, 

1900 

900, 
1800, 



MIDP1.0, CLDC 1.0 96x64 



MIDP1.0, CLDC 1.0 



MIDP 1.0, CLDC 1.0 



MIDP1.0, CLDC 1.0 



MIDP 1.0, CLDC 1.0 



MIDP 1.0, CLDC 1.0 



MIDP 1.0, CLDC 1.0 



1900 MIDP 1.0 



800, MIDP 1.0, CLDC 1.0 
1900 



800, MIDP 1.0, CLDC 1.0 
1900 



MIDP 1.0, CLDC 1.0 

WMA1.0, MMAPI 1.0, 
MIDP 1.0, CLDC 1.0 



96x64 
96x64 
96x64 

96x65/1 bit 
96x65/12 bits 
96x65/12 bits 
96x65/2 bits 
96x65/2 bits 

96x65/2 bits 

96x65/1 bit 
176x208/12 bits 



MIDP 1.0, CLDC 1.0 128x128/12 bits 



MIDP 1.0, CLDC 1.0 128x128/12 bits 



MIDP 1.0, CLDC 1.0 
MIDP 1.0, CLDC 1.0 



128x128/12 bits 



95x65/1 bit 



Avail, 
yet 

Yes 

Yes 

Yes 

Not 
yet 

Yes 

Not 
yet 

Yes 

Not 
yet 

Yes 



Not 
yet 

Yes 

Not 
yet 

Not 
yet 

Not 

yet 

Not 
yet 

Yes 



MIDP 1.0, CLDC 1.0 128x128/12 bits Yes 
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Manufacturer Model 

Nokia 
Nokia 
Nokia 
Nokia 



Wireless 
Technology 



Nokia 

Nokia 
Nokia 
Nokia 

Nokia 

Nokia 

Panasonic 

Research In 
Motion 



Research In 
Motion 



Samsung 
Samsung 
Samsung 
Samsung 
Samsung 



APPENDIX A 

Freq. 
(MHz) 

1900 



Software 



Screen 



Avail. 



6650 


GSM/GPRS, 
W-CDMA 


900, 
1800 


6800 


GSM/GPRS 


900, 
1800 


6800 


GSM/GPRS 


850, 
1900 


7210 


GSM/GPRS 


900, 

1800, 

1900 


7250 


GSM/GPRS 


900, 

1800, 

1900 


7650 


GSM/GPRS 


900, 
1800 


8910i 


GSM/GPRS 


900, 
1800 


9210 

Commu 

nicator 


GSM 


900, 
1800 


9210i 

Commu 

nicator 


GSM 


900, 
1800 


9290 

Commu 

nicator 


GSM 


1900 


C3003 
P 


CDMA 


800 


Blackb 

erry 

5810 


GSM/GPRS 


1900 


Blackb 

erry 

5820 


GSM/GPRS 


900, 
1800 


SCH- 
X130 


CDMA2000 
1X 


800 


SCH- 
X230 


CDMA2000 
1X 


800 


SCH- 
X250 


CDMA2000 
1X 


800 


SCH- 
X350 


CDMA2000 
1X 


800 


SGH- 
S100 


GSM/GPRS 


900, 

1800, 

1900 



MIDP1.0, CLDC1.0 



PersonalJava 1.1.1 



PersonalJava 1.1 .1 



JavaPhone 1.0, 
PersonalJava 1.1.1 



800 MIDP 1.0, CLDC 1.0 
1900 MIDP 1.0, CLDC 1.0 



800 MIDP 1.0, CLDC 1.0 

800 MIDP 1.0, CLDC 1.0 

800 MIDP 1.0, CLDC 1.0 

800 MIDP 1.0, CLDC 1.0 



128x160/12 bits Not 
yet 

128x128/12 bits Not 
yet 

128x128/12 bits Not 
yet 

128x128/12 bits Yes 



128x128/12 bits Not 
yet 

176x208/12 bits Yes 

96x65/12 bits Not 
yet 

640x200/12 bits Yes 



640x200/12 bits Yes 

640x200/12 bits Yes 

132x176/16 bits Yes 

160x160/1 bit Yes 

160x160/1 bit Yes 

128x128/2 bits Yes 

120x160/8 bits Yes 

120x160/8 bits Yes 

128x128/2 bits Yes 

128x160/16 bits Yes 
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Manufacturer 
Samsung 

Samsung 

Samsung 

Sanyo 

Sanyo 

Sanyo 

Sharp 
Sharp 
Sharp 
Siemens 

Siemens 

Siemens 

Sony Ericsson 

Sony Ericsson 

Toshiba 
Toshiba 
Toshiba 



Model 

SPH- 
A50Q 

SPH- 
N400 

SPH- 
X4209 

A3011 
SA 

SCP- 
4900 



SCP- 
5300 



J-SH07 
J-SH08 
J-SH51 
M50 



Wireless 
Technology 



Freq. 
(MHz) 



Software 



AMPS, CDMA 800, MIDP 1 .0, CLDC 1 .0 
1900 



Screen Avail. 
128x128/12 bits Yes 



AMPS, CDMA 

CDMA2000 
1X 

CDMA2000 
1X 

AMPS, 

CDMA2000 

1X 

AMPS, 

CDMA2000 

1X 

PDC 

PDC 

PDC 

GSM/GPRS 



SL42 GSM/GPRS 

SL45i/6 GSM 
6881 

A3014 CDMA2000 

S 1X 

P800 GSM/GPRS 



A3013T CDMA2000 
1X 

C5001 CDMA 
T 

J-T06 PDC 



800, 
1900 

800 



1500 

1500 

1500 

900, 
1800 

900, 
1800 

900, 
1800 

800 



MIDP 1.0, CLDC 1.0 128x96/16 bits Yes 
MIDP 1.0, CLDC 1.0 128x160 Yes 



800 MIDP 1.0, CLDC 1.0 



800, MIDP 1.0, CLDC 1.0 
1900 



800, MIDP 1.0, CLDC 1.0 
1900 



MIDP 1.0, CLDC 1.0 
MIDP 1.0, CLDC 1.0 
MIDP 1.0, CLDC 1.0 
MIDP 1.0, CLDC 1.0 



132x176/16 bits Not 
yet 

120x96/12 bits Yes 



128x132/16 bits Yes 

120x160/16 bits Yes 

122x162 Yes 

122x162 Yes 

101x64/1 bit Yes 



MIDP 1.0, CLDC 1.0 101x80/1 bit Yes 



MIDP 1.0, CLDC 1.0 101x80/1 bit Yes 



MIDP 1.0, CLDC 1.0 120x120/16 bits Yes 



900, MIDP 1.0, CLDC 1.0, 

1800, PersonalJava 1.1.1 
1900 

800 MIDP 1.0, CLDC 1.0 

800 MIDP 1.0, CLDC 1.0 



208x320/12 bits Not 
yet 

144x176/16 bits Not 
yet 

144x176/12 bits Yes 



1500 MIDP 1.0, CLDC 1.0 16 bits 



Yes 
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